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EHM  System  Technical  Capabilities 


1.0  Executive  Summary 


A  prototype  USAF  engine  health  management  (EHM)  system  was  developed  and  ground  tested 
during  this  Phase  II  SBIR  program.  The  EHM  system  is  capable  of  real-time  mechanical 
monitoring  and  diagnostics,  aero-thermal  performance  monitoring  and  diagnostics,  and  "engine 
signature"  based  life  accumulation.  For  the  first  time,  state-of-the-art  anomaly  detection, 
monitoring,  diagnosis  and  advanced  life  prediction  analysis  were  integrated  together  in  a  single 
real-time  engine  health  monitoring  system.  Additionally,  the  EHM  system  was  developed  to 
assist  the  2-level  maintenance  concept  and  IHPTET  initiatives. 

The  modular  EHM  system  consists  of  four  principal  operating  subsystems;  they  are  the  data 
management,  health,  diagnostic,  and  engine  life  engineering  modules.  Within  these  four 
modules,  mechanical  and  performance  related  anomaly  detection  and  diagnostics,  mission-based 
life  usage,  sensor  validation,  virtual  sensing,  and  long/short  trending  capabilities  are  performed 
in  real-time.  The  real-time  operation  of  the  four  modules  is  performed  simultaneously  within  a 
PC-based  computing  structure  under  the  Windows®  NT  operating  system.  Data  transfer  and 
real-time  analysis  was  accomplished  automatically  within  the  flexible  modular  subsystems, 
allowing  for  the  customized  development  of  an  EHM  system  for  any  chosen  USAF  engine.  EHM 
system  modules  can  now  be  developed  for  any  class  of  engine,  with  engine  specifics  being 
incorporated  into  the  engine  specific  diagnostic  networks  and  algorithms  after  initial  system 
installation. 

The  prototype  EHM  system  was  ground  test  verified  on  three  (3)  F405  (Adour)  engines  during 
production  pass-off  testing  at  Rolls-Royce  pic  in  Bristol,  England.  Results  from  EHM  system 
testing  and  follow-up  analysis  emphasized  that  an  important  balance  must  exist  between  the 
real-time  diagnostic  capabilities  and  the  ability  to  deal  with  “real  world”  uncertainties  from 
sensor  signal  transients,  random  measurement  fluctuations  and  non  steady-state  performance 
and  vibration  parameter  changes.  Therefore,  based  on  the  results  obtained  from  the  ground 
testing,  the  developed  EHM  system  demonstrated  the  ability  to  perform  real-time  diagnosis  of 
sensor  signals,  mechanical/performance  faults,  and  life  usage  estimates  associated  with  the  F405 
(Adour)  engine. 

A  Phase  HI  program  extending  the  principles  demonstrated  herein  is  currently  underway  that 
includes  the  development  of  a  customized  EHM  system  for  the  GE  F101  USAF  engine. 
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2.0  Program  Overview  and  Objectives 
2.1  Overview 

The  integration  of  life,  vibration  and  performance  monitoring/diagnostics  that  is  capable  of 
detecting  and  classifying  developing  engine  faults  is  critical  to  reducing  engine  operating  and 
maintenance  costs  while  optimizing  the  life  of  “hot  section”  engine  components.  A  modular, 
comprehensive  engine  health  monitoring  (EHM)  system  capable  of  integrated  mechanical, 
performance,  and  life  based  monitoring  has  been  developed  in  this  Phase  II  SBIR  program. 

Engine  data  currently  sensed  and  recorded  for  post  flight  processing  is  now  analyzed  in  a 
continuous  real-time  mode  as  demonstrated  in  this  program.  The  measured  data  from  the 
EHM  system  is  passed  to  redundant  anomaly  detection  routines  for  analyzing  both 
performance  and  mechanical  related  faults.  These  routines  were  developed  based  on  extensive 
knowledge  of  how  healthy  engines  operate  under  a  range  of  operating  conditions,  and  any 
deviation  from  this  “normal”  pattern  of  expected  parameters  will  be  detected  and  further 
analyzed.  Faults  resulting  from  sensor  failure  modes  will  be  promptly  isolated  in  the  EHM 
“data  management”  module,  while  more  complex  faults  will  be  identified  by  pattern 
classification  schemes  in  the  “health”  and  “diagnostic”  modules. 

Also  developed  during  this  program,  advanced  technologies  for  “virtual  sensing”  currently 
unmeasured  engine  parameters  such  as  turbine  entry  temperature  (TET)  are  used  for  input  to 
critical  component  lifing  algorithms.  As  a  result,  component  life  usage  was  determined  more 
accurately  based  on  real-time,  model-based  parameter  estimates  and  actual  engine  conditions. 


2.2  Objectives 

The  principal  objective  of  this  Phase  II  SBIR  program  was  to  develop  a  prototype  Engine  Health 
Monitoring  (EHM)  system  capable  of  real-time  mechanical  diagnostics,  aero-thermal 
performance  monitoring,  and  critical  component  life  usage.  These  aspects  of  the  developed 
EHM  system  were  directly  coupled  to  an  individual  engine's  mission  profile  and  operating 
conditions.  The  architecture  of  the  EHM  system  was  influenced  by  the  integration  of  existing 
technologies,  namely  neural  networks,  fuzzy  logic,  and  probabilistic  life  prediction  analysis,  and 
has  advanced  the  current  state-of-the-art  in  USAF  engine  monitoring  systems.  The  ultimate 
objective  of  the  EHM  system  was  to  minimize  scheduled/unscheduled  engine  downtime, 
maintenance  manpower  and  component  failures,  while  maximizing  engine  reliability  through 
more  accurate  and  timely  diagnosis  and  life  measurement  capabilities. 

A  more  detailed  description  of  the  Phase  II  program  objectives  is  given  below.  This  is  the  same 
list  that  was  given  in  the  original  Phase  II  proposal,  and  as  one  can  see,  these  objective  have 
been  satisfied  under  this  program. 
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1. )  Incorporate  a  more  realistic  measure  of  the  engine  operating  life  through  better 

utilization  of  the  currently  measured  and  calculated  parameters  in  component  life 
accumulation  algorithms. 

2. )  Develop  artificial  intelligence  based  modules  for  performing  both  real-time  engine 

diagnostics  and  trend-based,  long  term  mechanical  diagnostics,  and  aero-thermal 
performance  monitoring. 

3. )  Integrate  engine  component  diagnostics,  life  usage,  and  trending  capabilities 

within  a  modular  data  processing  structure.  Health,  diagnostic,  data  management, 
and  life  modules  will  be  developed  for  the  F405  (Adour)  engine  on  the  T45 
trainer. 

4. )  Enhance  current  low  cycle  fatigue  (LCF)  based  life  usage  algorithms  to  include 

temperature  and  material  creep  effects.  Produce  more  realistic  component  life 
estimates  based  on  better  mission  representative  information. 

5. )  Improve  the  timeliness  by  increasing  automation  and  reducing  the  human 

intervention  required  with  current  monitoring  systems.  Calculating  engine  life 
usage  at  the  end  of  each  mission  and  offer  a  comprehensive  diagnostic  report. 

6. )  Develop  real-time  engine  diagnostic  networks  in  parallel  with  trended  data  expert 

systems  to  address  the  problem  of  fault  severity  and  duration 

7. )  Develop  fuzzy  logic  and  deductive  reasoning  algorithms  to  determine  the  causes 

for  the  diagnosed  failures  or  degraded  performance. 

2.3  Current  USAF  Trending/Diagnostic  Systems 

Current  USAF  engine  health  monitoring  systems  have  many  inefficiencies  that  can  be  overcome 
with  the  integration  of  advanced  monitoring/diagnostic  and  life  prediction  technologies.  Some  of 
the  current  trending  system  shortcomings  include;  1.)  Data  collection/trending  is  cumbersome 
and  tedious,  2.)  Diagnosis  and  recommended  maintenance  is  only  obtained  from  experienced 
individuals  who  can  analyze  the  trended  data,  3.)  Human  misinterpretation  of  data  and  labor 
intensive,  4.)  Life  accumulation  is  primarily  based  on  TAC  cycles,  little  account  for  thermal  or 
vibratory  effects,  5.)  Exhaustive  data  transfer  mechanisms,  and  6.)  Considerable  time  is  needed 
to  make  a  thorough  diagnosis,  resulting  in  delayed  maintenance.  Figure  1  is  an  illustration  of  the 
current  labor  and  data  intensive  monitoring  system,  with  its  several  interfaces. 
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Figure  1  Current  USAF  Monitoring  System  Configuration 


2.4  Benefits  of  EHM  System 

As  a  result  of  real-time  engine  diagnostics  and  more  representative  engine  component  life 
predictions,  gas  turbine  engines  will  undoubtedly  become  more  reliable  and  more  efficiently  and 
economically  maintained.  This  will  be  accomplished  through  proper  management  of  engine 
performance  degradation,  reduced  scheduled  and  unscheduled  downtime,  lengthened  inspection 
intervals,  and  improved  logistics  through  advanced  maintenance  planning.  Achieving  these  goals 
will  undoubtedly  help  support  2-level  maintenance  and  the  IHPTET  initiative 

As  an  example  of  the  cost  savings  that  can  be  realized  with  the  implementation  of  more  "mission 
representative"  engine  life  prediction  schemes  (therefore  being  able  to  safely  increase  inspection 
intervals),  consider  the  following  5  year  study  associated  with  the  inspection  of  engine  disks. 
Over  the  five  year  period  extending  from  October  1986  to  September  1991,  approximately 
15,000  disks  were  inspected  for  safety  critical  size  cracks.  Of  the  15,000  disks  inspected, 
approximately  13,000  of  those  disks  were  returned  to  service  without  rework  or  modifications. 
The  economic  savings  that  could  be  gained  from  reducing  this  maintenance  effort  by  a  realistic 
20-40  percent,  while  maintaining  current  safety  requirements,  would  be  great. 


From  a  technical  point  of  view,  the  application  of  advanced  fault  classifiers/algorithms  to  real¬ 
time  engine  diagnostics  and  more  mission  representative  lifing  algorithms,  current  engine  health 
monitoring  systems  can  be  improved  significantly.  In  particular,  the  incorporation  of  neural 
networks  into  the  diagnostic  process  will  yield  great  benefits  in  terms  of  processing  speed, 
robustness,  knowledge  acquisition,  and  adaptability.  Other  important  technical  benefits  of 
applying  AI  and  advanced  life  prediction  schemes  to  condition  monitoring,  diagnosis,  and  life 
usage  are  as  follows: 


5 


1. )  Enhanced  ability  to  capture,  organize,  and  utilize  all  relevant  data,  experience,  and  rules 

within  a  massively  parallel,  interconnected  processing  modules. 

2. )  Provides  an  automated  procedure  for  incorporating  data  from  several  knowledge  sources 

including;  analytical  FEM  models,  aerothermal  performance  models,  empirical/trended 
test  data,  and  heuristic  (rules  based)  experience. 

3. )  Neural  network  system  architectures  are  well  suited  for  processing  large  quantities  of 

non-linear,  multidimensional,  coupled  parameters  such  as  temperatures,  pressures,  etc. 
that  occur  within  a  gas  turbine  engine. 

4. )  Utilizing  advanced  diagnostic  algorithms  results  in  a  process  that  is  less  dependent  on 

human  experts  and  more  automated  to  facilitate  quick  decision  making. 

5. )  Incorporating  more  information  (i.e.  currently  unmeasured  parameters)  into  the  proposed 

life  accumulation  algorithms  will  provide  a  more  accurate  outlook  on  the  remaining  life 
of  critical  engine  components. 
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3.0  Program  Technical  Approach 

The  technical  approach  and  system  development  concept  followed  in  this  program  is  outlined 
below.  Engineering  module  development,  hardware  issues  (sensor  signal  processing),  software 
development,  and  system  testing  are  examined  in  general  terms. 

3.1  EHM  Technical  Approach 


The  real-time  data  acquisition  scheme  and  structured  database  that  exists  at  the  core  of  the  data 
management  module  was  developed  at  the  outset.  The  database  architecture,  incorporating 
multi-processing  techniques  and  priority  system  interrupts  was  also  developed  at  the  start.  A 
comprehensive  database  of  engine  parameter  thresholds  and  ranges  was  initially  compiled  as  a 
first  condition  with  which  to  compare  inflowing  data.  Engine  data  sensed  out  of  these  desired 
operating  ranges,  as  determined  from  the  “engine  signature  models,  triggers  the  health  and 
diagnostic  modules  to  examine  current  and  trended  data  patterns  for  component  faults  and 
subsequent  prognosis.  An  F405  (Adour)  engine  aero-thermal  performance  model  was  used  to 
“virtually  sense”  the  significant  engine  parameters  that  are  not  directly  measured,  i.e  turbine 
inlet  temperature,  etc. 

Engine  signature  based  anomaly  detection  utilizing  fuzzy-logic  and  associated  rule  bases  were 
used  in  the  health  module  to  detect  engine  anomalies  (both  mechanical  and  performance  related). 
The  fuzzy-logic  based  anomaly  detection  was  developed  from  non-normal  deviation  from  the 
“engine  signature”  models.  In  addition,  trended  data  algorithms  were  developed  to  sample  data 
at  precise  and  consistent  instances  during  take-off  conditions.  This  data  was  passed  on  to 
dedicated  algorithms  which  interfaced  with  the  real-time  network  diagnostics  for  determining 
fault  severity  and  duration.  The  F405  (Adour)  engine  synthesis  model  and  ground  test  data 
supplied  by  Rolls-Royce  pic.  were  used  to  develop  fault  patterns  associated  with  aero-thermal 
performance  and  vibration  issues. 

Pattern  recognition  utilizing  neural  networks,  with  pre  and  post  processing  capabilities,  formed 
the  heart  of  the  EHM  diagnostic  module.  Critically  identified  fault  conditions  with  the  most 
significant  behavioral  pattern  relationships  were  initially  identified  so  that  network  architectures 
could  be  developed.  Recognized  fault  pattern  diagnosis  was  accomplished  in  the  diagnostic 
module  using  a  combined  fuzzy  logic  and  neural  network  approach.  The  neural  network 
input/output  patterns  were  “clustered”  using  Kohonen  Self  Organizing  Maps  and  further  used  to 
develop  the  fuzzy  logic  reasoning  algorithms  based  on  engine  through  flow  models  and 
experimental  case  histories.  Diagnosed  engine  conditions  that  yield  similar  fault  patterns  were 
differentiated  within  this  module  and  verified  with  the  use  of  the  F405  (Adour)  engine  model. 

The  engine  life  module  analyzed  the  remaining  life  of  the  HP  turbine  blades  and  disk  using 
BLADE  GT  (disk/blade)  and  Rolls-Royce  provided  empirical  formulas  to  determine  the  amount 
of  life  consumption  per  sortie.  Critical  component  life  design  algorithms  used  in  the 
development  of  the  F405  (Adour)  engine  were  included  in  the  EHM  life  accumulation  algorithm. 


3.2  EHM  Capabilities  and  Architecture 
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Figure  2  illustrates  a  block  diagram  of  the  capabilities  that  are  built  into  the  developed  EHM 
system.  The  four  modules  that  perform  the  data  management,  health,  diagnostic  and  engine  life 
functions  operate  simultaneously,  transferring  real-time,  trended,  diagnostic,  and  component  life 
data  between  the  modules  as  needed. 

The  main  responsibility  of  the  Data  Management  Module  is  to  acquire  the  real-time,  sensed 
engine  data.  Next,  the  module  utilizes  a  neural  network  predictor  architecture  to  perform  several 
quality  control  checks  to  ensure  the  integrity  of  the  sensed  data.  Once  the  data  is  thoroughly 
checked,  a  larger  set  of  engine  parameters  are  derived  from  the  directly  sensed  engine 
parameters  using  a  standard  back  propagation  network  architecture.  This  larger  set  of  engine 
parameters  is  used  in  the  health  and  diagnostic  modules.  An  engine  duty  monitor  is  also  present 
in  the  data  management  module.  Engine  life  is  accumulated  based  on  LCF  and  thermal  cycles 
and  is  presented  as  a  fraction  of  total  available  life  for  both  the  HP  turbine  blades  and  disk.  The 
final  function  performed  in  this  module  was  overall  system  data  storage  and  retrieval.  Raw 
sensed  data,  trended  data,  diagnosis  results  and  engine  life  accumulation  reports  are  all  stored  in 
this  sub-module. 

The  Health  Module  is  dedicated  to  examining  the  real-time  engine  parameter  data  set,  trending  it 
over  time,  and  detecting  any  initial  anomalies  associated  with  the  engine.  Specific  trend  patterns 
and  parameter  ratios  are  taken  at  precise  times  during  take-off  to  ensure  consistent  and  accurate 
trending  information.  When  an  acquired  engine  parameter  is  detected  as  falling  outside  the 
“normal”  engine  operating  signature,  it  is  forwarded  to  the  diagnostic  module  for  detailed 
examination.  Based  on  the  trended  data  and  fault  pattern  recognized,  the  severity  and  duration  of 
the  recognized  fault  is  also  determined.  In  this  procedure,  the  difference  between  a  sudden  or 
abrupt  fault  can  be  distinguished  from  a  slowly  degrading  engine  performance  related  concern. 

Once  data  is  transferred  to  the  Diagnostic  Module,  dedicated  neural  networks  and  fuzzy  logic 
based  algorithms  determine  the  cause  of  the  diagnosed  failure  or  degraded  performance.  The 
neural  networks  developed  and  implemented  in  the  health  module  are  based  on  a  Self  Organizing 
Kohonen  Map  that  clusters  similar  fault  patterns  and  passes  them  to  a  standard  back-propagation 
network  that  classifies  the  particular  fault.  The  combination  of  these  neural  networks  make  it 
easy  to  examine  and  identify  faults  patterns  from  the  clusters  and  not  just  rely  on  the  “black  box” 
approach  of  using  a  single  back-propagation  neural  network.  This  “back-to-back”  neural 
network  approach  is  also  very  robust  with  respect  to  sensor  noise  and  parameter  uncertainty. 

During  a  mission  or  test,  data  from  the  engine  duty  monitor  within  the  Data  Management 
Module  is  continuously  being  transferred  to  the  Engine  Life  Module  so  that  "mission 
representative"  life  may  be  accumulated.  The  life  accumulation  algorithm  will  include  the  engine 
specific  parameters  tracked  throughout  the  entire  mission.  Hot  section  temperatures  and 
corresponding  material  creep  will  be  determined  and  used  as  input  to  the  life  accumulation 
algorithms.  At  the  end  of  the  mission,  critical  component  life  accumulated  during  that  mission  is 
reported  and  transferred  back  to  the  trending  module  for  overall  accumulation  of  each 
components  life  usage. 
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Figure  2  Engine  Health  Monitoring  System  Capabilities 


3.3  Adour-Navy  F405  Turbofan  Engine  Description 

The  Rolls-Royce  Turbomeca  Adour  (F405)  turbofan  engine  is  now  in  general  use  as  the 
powerplant  for  several  subsonic  combat  aircraft  and  advanced  trainer  aircraft.  The  engine  was 
originally  designed  to  the  requirements  of  the  British  and  French  Governments  for  the  Jaguar 
aircraft,  which  is  in  operational  service  with  the  Air  Forces  of  both  governments.  A  similar 
power  unit  is  fitted  to  the  Japan  T-2  trainer  and  Japan  F-l  fighter  support  aircraft  in  service  with 
the  Japan  Air  Self-Defense  Force. 

An  unaugmented  version  of  the  engine  is  fitted  to  the  British  Aerospace  Hawk  in  service  with  the 
Royal  Air  Force,  and,  designated  as  F405-RR-401,  is  fitted  in  the  McDonnell  Douglas  T45A 
Goshawk  trainer  for  the  US  Navy.  The  F405-RR-401  shown  in  Figure  3  is  a  two-shaft  turbofan 
engine  with  medium  bypass  and  pressure  ratios. 

There  are  a  total  of  seven  stages  of  compression,  two  on  the  low  pressure  (LP)  compressor  and 
five  on  the  high  pressure  (HP)  compressor.  Neither  of  the  compressors  are  fitted  with  inlet 
guide  vanes  and  there  are  no  variables  apart  from  a  simple  bleed  valve  which  operates  only 
during  starting.  Steel  and  titanium  are  extensively  used  in  the  compressor  blading  and  all  blades 
are  of  wide  chord  with  large  axial  clearances  between  blade  rows  giving  a  high  resistance  to  the 
effects  of  foreign  object  ingestion. 

An  annular  combustion  chamber  makes  possible  a  reduction  in  the  engine  length,  volume  and 
weight  relative  to  tubular  and  annular  systems.  Temperature  distribution  can  be  improved 
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minimizing  surface  cooling  requirements,  and  the  interconnection  problems  associated  with 
individual  flame  tubes  are  eliminated. 

The  18  air  spray  burners  are  designed  such  that  air  passes  through  a  central  passage  in  the  burner 
head  picking  up  fuel  from  an  annular  gallery.  The  fuel/air  mixture  is  formed  into  a  spray  by 
passing  over  a  cone  and  the  spray  profile  is  controlled  by  a  further  air  flow  passing  externally 
over  the  burner  head.  Ignition  is  by  two  igniter  plugs. 

The  engine  main  journal  bearings  are  fitted  inside  "squeeze  film"  mountings  in  which  the  bearing 
outer  track  is  supported  on  a  thin  annular  cushion  of  oil  fed  from  the  normal  oil  system,  as 
shown  in  Figure  4.  Squeeze  film  mountings  reduce  the  forces  transmitted  between  the  engine 
rotors  and  casings,  lessening  vibration  and  giving  improved  component  life,  particularly  to  sheet 
metal  parts  and  accessory  units. 

The  HP  and  LP  turbines  are  each  single  stage.  The  high  pressure  nozzle  guide  vanes  feature  an 
advanced  system  of  air  cooling  including  impingement  and  film  cooling  at  the  leading  edge, 
internal  ribs  and  pedestals  to  maximize  head  dissipation  in  the  airfoil,  and  cooling  air  ejection 
through  slots  in  the  trailing  edge. 


THRUST  GROWTH 

Revised  low 
pressure  compressor 


Higher  turbine  operating  temperatures 


IMPROVED 
SPECIFIC  FUEL  CONSUMPTION 


Figure  3  F405  (Adour)  Turbo  Fan  Engine 
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The  major  components  of  the  rotating  assemblies  are  joined  by  curvic  couplings  which  provide 
complete  location  by  means  of  meshing  teeth  on  the  mating  faces.  These  components  can 
therefore  be  assembled  without  the  need  for  individual  fitting,  such  as  taper  reaming,  at  each 
joint.  The  increased  ease  of  assembly  makes  modular  exchange  practicable  for  major  rotating 
components  in  the  same  way  as  for  static  assemblies.  A  single  external  gearbox  is  fitted  which  is 
driven  off  the  HP  rotor. 

The  Adour  engine  in  its  various  non-afterburning  forms  is  available  at  thrust  levels  between  5200 
and  5990  lbf.  As  an  example  the  performance  of  the  Mk  871  engine,  of  which  the  F405  is  a 
modified  version,  is  given  below. 


1.) 

Take-off  thrust 

5990  lbf. 

2.) 

Bypass  Ratio 

0.76:1 

3.) 

Overall  Pressure  Ratio 

11.3:1 

4.) 

Basic  Power  Unit  weight 

1299  lbs 

5.) 

Length 

77  ins 

6.) 

Intake  diameter 

22ins. 

The  basic  features  of  the  engine,  as  a  two-shaft  turbofan  engine,  is  typical  of  the  engines  in  most 
gas  turbine  powered  military  aircraft  today  and,  therefore,  and  ideal  vehicle  for  evaluating  and 
demonstrating  the  features  of  an  intelligent  engine  health  and  life  monitoring  system. 

F405  (Adour)  Engine  Instrumentation 

The  F405  service  engine  is  fitted  with  various  sensors  which  enabled  the  features  of  the  EHM 
system  to  be  comprehensively  evaluated.  The  specific  instrumentation  is  shown  schematically  in 
Figure  5  below  and  consists  of: 


1.) 

LP  spool  shaft  speed 

NL 

2.) 

HP  spool  shaft  speed 

NH 

3.) 

HP  compressor  delivery  pressure 

P3 

4.) 

LP  compressor  delivery  pressure 

T2 
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5.) 

Jet  pipe  temperature 

T6 

6.) 

Fuel  flow 

Wf 

7.) 

Vibration  transducer  &  charge  amp. 

Vb 

No  1  hydraulic  pump  Control  input 


Figure  5  Adour  Engine  Instrumentation 

In  addition,  on  the  T-45A  Goshawk,  the  following  data  is  available  from  the  Aircraft  Data 
Recorder  system: 


1. )  Power  Lever  Angle  PLA 

2. )  Ambient  Pressure  Po 

3. )  Ambient  Temperature  To 

4. )  Altitude  Alt 

5. )  Mach  No  Mn 


F405  (Adour)  Engine  Aero-thermal  Performance  Model 

A  complete  aero-thermodynamic  model  of  the  engine  is  available  within  the  RRAP  (Rolls-Royce 
Aerothermal  Performance)  Computer  Synthesis.  This  model  provided  the  necessary  algorithms 
for  data  reduction  and  additional  parameter  calculation  within  the  EHM  system.  It  was  also 
used,  together  with  an  extensive  empirical  database,  to  generate  a  knowledge  base  for  the  neural 
net  evaluation  of  engine  status. 
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4.0  EHM  System  Development 

The  following  section  will  describe  the  engineering  developments  and  operations  of  the  Engine 
Health  Monitoring  system.  The  specific  algorithms  and  mathematical  framework  that  was 
used  in  developing  the  EHM  system  will  be  presented  in  each  of  the  functional  modules 
described  below. 

4.1  EHM  Engineering  Modules 

The  Engine  Health  Monitoring  system  developed  under  this  SBIR  program  consists  primarily 
of  four  engineering  modules  that  will  perform  sensor  validation/recovery,  trending,  anomaly 
detection,  diagnostics,  and  life  usage  functions.  The  four  modules  are  named  (1)  data 
management,  (2)  health,  (3)  diagnostic  and  (4)  engine  life  and  operate  simultaneously, 
transferring  real-time,  trended,  diagnostic,  and  component  life  data  between  the  modules  as 
needed.  The  basic  block  diagram  illustrating  the  functionality  of  each  module  is  given  below 
in  Figure  6. 
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Figure  6  EHM  Engineering  Modules 
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4.2  Data  Management  Module 


The  primary  function  of  the  Data  Management  Module  is  to  acquire  the  real-time,  sensed 
engine  data.  In  doing  so,  the  module  utilizes  a  feed-forward  neural  network  predictor 
architecture  to  perform  several  quality  control  checks  to  ensure  the  integrity  of  the  sensed 
data.  Once  the  data  is  thoroughly  checked,  additional  engine  parameters  are  predicted  in  real¬ 
time  from  the  directly  sensed  engine  parameters  using  a  standard  back  propagation  network 
architecture  trained  by  “engine  synthesis”  models.  Hence,  currently  unmeasured  engine 
parameters  such  as  turbine  entry  temperature  (TET)  can  be  predicted  and  utilized  in  real-time 
just  as  the  directly  sensed  parameters.  These  “virtually  sensed”  engine  parameters  are  then 
used  in  the  engine  life  module  to  obtain  more  accurate  and  realistic  measures  of  hot  component 
life  parts.  An  engine  duty  monitor  is  also  present  in  the  data  management  module.  Engine 
life  is  accumulated  based  on  LCF,  creep,  and  thermal  cycles  and  is  presented  as  a  fraction  of 
total  available  life.  The  final  function  to  be  performed  in  this  module  is  overall  system  data 
storage  and  retrieval.  Raw  sensed  data,  trended  data,  diagnosis  results  and  engine  life 
accumulation  reports  are  all  stored  in  this  sub-module. 

One  of  the  most  critical  functions  of  the  data  management  module  will  be  to  evaluate  the 
quality  of  the  measured  signals.  This  will  include  both  tolerance  bands  as  a  function  of  a 
baseline  parameter  and  the  use  of  pattern  matching  with  a  database  of  known  signal  sets.  Any 
anomalous  signals  will  be  identified  and  evaluated  in  comparison  with  the  other  prevailing 
signals  to  decide  on  acceptability  or  need  for  repair.  As  an  example  of  data  repair  it  may  be 
necessary  to  recompute  the  average  jet  pipe  temperature  as  a  result  of  a  loss  of  one  of  the  12 
T6  thermocouples.  If  the  signal  is  erroneous  and  cannot  be  repaired,  a  decision  flow  path 
manages  subsequent  analysis  to  account  for  the  missing  signal. 

This  submodule  will  also  record  any  limit  exceedances  in  addition  to  the  normal  engine  control 
unit  function.  It  will  flag  any  overspeeds,  pressure  or  temperature  exceedances  and  record 
data  until  the  exceedance  event  is  over. 

4.2.1  Sensor  Validation  and  Recovery  System 

An  advanced  sensor  validation  scheme  capable  of  detecting  failed  sensor  hardware  without 
sensor  redundancy  and  during  non-steady  state  monitoring  conditions  is  a  necessary  “front 
end”  to  the  EHM  system.  The  developed  approach  utilizes  neural  networks  and  fuzzy  logic  to 
accomplish  the  desired  goal  (Harrison  and  Harrison,  1994)  (Holbert  et  al.,  1994).  Neural 
networks  are  used  to  recognize  the  non-linear,  inter-relationships  between  the  different  types 
of  sensors  used  in  either  a  transient  or  steady-state  measurement  environment  (Lee,  1994). 
Fuzzy  logic  is  used  to  pre-  and  post-process  the  measurement  data  in  order  to  determine 
general  characteristics  about  the  state  of  operation  of  the  engine. 
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A  block  diagram  of  the  sensor  validation  system  architecture  is  given  in  Figure  7.  The 
speed/power  sensor  data  is  first  accepted  by  two  parallel  fuzzy  logic  modules.  The  first 
module  determines  the  state  of  the  speed/power  condition  (i.e  increasing,  decreasing,  or 
steady-state)  and  the  second  verifies  the  validity  of  speed/power  sensor  itself.  The  output  of 
the  speed/power  condition  module  triggers  a  particular  neural  network  module  that  was 
specifically  trained  to  know  the  sensor  relationships  for  either  increasing,  decreasing  or  steady 
power  output.  Only  one  neural  network  modules  is  triggered  at  a  time,  depending  on  the 
outcome  of  the  prior  fuzzy  logic  decisions.  The  sensor  confidence  values  predicted  by  the 
neural  networks  are  trended  over  time  and  passed  through  another  fuzzy  logic  module  to 
interpret  the  results.  These  extra  steps  are  used  to  ensure  that  false  alarms  do  not  occur. 

For  the  Adour  (F405)  engine  application  discussed  herein,  there  are  four  primary  performance 
related  sensors  (along  with  LP  and  HP  rotor  speeds)  that  are  measured  during  turbine 
operation.  These  sensors  include;  fuel  flow  (Wf),  HP  compressor  delivery  pressure  (P3),  LP 
compressor  delivery  temperature  (T2),  and  Jet  Pipe  temperature  (T6).  The  developed  neural 
network  utilized  a  multi-layered,  feed-forward  architecture  with  six  input  nodes,  five  output 
nodes,  and  one  hidden  layer  with  13  nodes.  The  outputs  of  the  neural  networks  yield  a 
confidence  factor  associated  with  the  probability  of  a  failed  sensor.  A  confidence  factor  near 
one  represents  proper  sensor  operation,  while  a  confidence  factor  near  zero  indicates  a  faulty 
sensor  mode.  A  fuzzy  logic  module  is  used  at  the  output  of  these  neural  networks  to  decide 
whether  the  sensor  is  good,  bad,  or  somewhere  in  between.  For  instance,  if  a  hard  decision 
was  utilized  to  alert  the  crew  when  a  sensor  confidence  factor  reached  a  level  less  than  0.80, 
false  alarms  would  likely  occur  even  though  a  sensor  confidence  factor  of  0.78  might  still 
indicate  a  properly  working  sensor. 


SENSOR  VALIDATION  SYSTEM  ARCHITECTURE 
(NON-REDUNDANT;  NON-STEADY  STATE) 


Figure  7  Sensor  Validation  Scheme 
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Neural  Network  Architecture  and  Training 


Two  different  neural  network  architectures  were  examined  for  this  application.  Both  networks 
utilized  a  multi-layered,  feed-forward  architecture  with  five  input  nodes  and  four  output  nodes.  The 
first  network  contained  one  hidden  layer  with  13  nodes  and  the  second  used  2  hidden  layers  with  10 
and  5  nodes  respectively. 

Determining  the  “optimal”  number  of  hidden  layers  and  nodes  for  each  network  is  a  non-trivial 
task  and  depends  on  many  factors,  some  of  which  include;  number  of  input/output  nodes,  quantity 
and  accuracy  of  training  data,  complexity  of  problem,  and  resulting  network  generalization 
performance.  The  “standard”  feed-forward  architectures  used  for  this  problem  were  picked  due  to 
the  large  quantity  of  training  data  available  and  the  resulting  network  generalization  performance 
required. 

The  simulated  gas  turbine  engine  data  used  to  train  the  neural  network  architectures  was  generated 
from  the  engine  synthesis  model.  The  data  set  represents  sensed  fuel  flow,  pressure,  and 
temperature  readings  during  a  start-up  condition.  Simultaneously  measured  data  staying  within  the 
illustrated  confidence  limits  for  each  sensor  would  represent  properly  operating  sensors.  Data 
going  outside  these  limits  would  indicate  a  failure  mode  associated  with  the  particular  sensor.  For 
training  purposes,  any  measurement  within  the  confidence  limits  of  each  sensor  for  a  particular 
engine  speed  would  indicate  a  sensor  confidence  level  of  1.0  (highest  confidence).  As  a  sensor 
measurement  moves  outside  the  confidence  limits,  the  neural  network  output  confidence  level 
decreases  from  1.0  towards  0.0  indicating  the  graduating  sensor  failure  mode.  Each  network 
architecture  was  subjected  to  the  same  training  data  set  consisting  of  300  input/output  pairs. 

Training  the  sensor  validation  networks  was  accomplished  with  a  supervised  learning  procedure. 
Each  of  the  300  training  pairs  or  patterns  used  during  the  training  process  consisted  of  5  sensor 
input  signals  and  it’s  corresponding  set  of  4  outputs  sensor  confidence  factors.  The  input  and 
output  training  data  was  normalized  to  values  between  0  and  1.  An  error-back-propagation 
algorithm  was  used  to  minimize  the  mean-squared  error  between  the  actual  network  output  and  the 
target  values  set  by  the  training  set.  Training  parameters  such  as  the  learning  rate,  gain  of  the 
activation  function,  and  momentum  coefficient  were  adapted  during  the  training  session  to  aid  in 
minimizing  the  error.  A  final  RMS  error  associated  with  all  training  pairs  was  reduced  to  0. 1 99. 

Sensor  Validation  Neural  Network  Results 


A  computer  generated  data  file  simulating  normal  and  faulty  sensor  measurements  was  developed 
to  test  the  accuracy  of  the  two  neural  network  architectures.  Figure  8  is  an  illustration  of  a  small 
section  of  that  file  including  a  range  of  fuel  flow  measurement  data.  The  data  represented  by  the  + 
signs  are  all  within  the  confidence  limits  of  normal  operating  sensor  patterns.  In  this  case,  sensor 
confidence  levels  predicted  by  the  neural  network  should  all  be  close  to  one.  The  data  indicated  by 
X’s  and  O’s  are  outside  the  confidence  limits  and  therefore  indicate  worsening  sensor  operation. 
The  X’s  are  just  outside  the  confidence  limits  and  should  predict  sensor  confidences  between  zero 
and  one.  The  O’s  are  significantly  outside  the  sensor  confidence  band  and  should  predict  sensor 


Wf  (Fuel  Flow  %) 


confidence  levels  close  to  zero.  The  results  from  this  data  file  are  given  in  Table  1  below.  Note, 
the  other  sensor  measurements  including  temperatures,  pressure,  and  speed  were  all  within  the 
confidence  limits. 


Table  1  Neural  Network  Results 


Case# 

“x” 

“o” 

1 

0.9197 

0.2711 

0.0755 

2 

0.9990 

0.1674 

0.0543 

3 

0.9990 

0.2625 

0.0923 

4 

0.9861 

0.7777 

0.0500 

5 

0.9990 

0.7700 

0.0923 

6 

0.9990 

0.7852 

0.1061 

7 

0.9756 

0.2378 

0.4670 

8 

0.9112 

0.1263 

0.0380 

9 

0.9734 

0.8133 

0.1389 

10 

0.9723 

0.3508 

0.1736 

11 

0.8831 

0.9244 

0.4835 

12 

0.9259 

0.9549 

0.4616 

13 

0.8556 

0.6185 

0.2459 

14 

0.9345 

0.9057 

0.0980 

15 

0.9057 

0.7111 

0.1866 

Note:  The  network  output  confidence  levels  for  the  other  sensors  were  all  above  0.975  for 
“+”  test  cases,  above  0.927  for  the  “x”  test  cases,  and  above  0.946  for  the  “o”  test 
cases. 

Several  test  cases  similar  to  the  results  described  in  Table  1  were  conducted  for  the  other  sensor 
measurements,  all  yielding  similar  results.  Although  the  trained  network  yielded  good  results  in 
terms  of  accuracy  and  generalization  capabilities,  overtraining  was  a  concern  that  was  monitored 
carefully.  Initially,  600  training  patterns  were  used  to  train  the  network  with  output  error  similar  to 
the  300  training  pattern  case.  The  resultant  trained  network  had  much  worse  generalizing 
capabilities  than  the  network  trained  with  only  300  patterns. 

The  network  architecture  with  two  hidden  layers  was  trained  and  tested  with  the  same  data  as  used 
for  the  previous  single  hidden  layer  network.  In  this  case,  the  output  RMS  error  was  only  reduced 
to  0.289  and  the  network  generalization  capability  degraded.  The  worsened  generalization 
capability  can  be  explained  by  the  additional  degrees  of  freedom  that  were  introduced  by  the 
additional  nodes  (neurons)  in  the  hidden  layers.  The  higher  network  RMS  error  is  most  likely  due 
to  finding  a  “local”  minimum  associated  with  the  gradient  decent  BPE  algorithm.  In  theory,  the 
error  should  have  been  reduced  to  at  least  the  level  of  the  previous  single  hidden  layer  network. 

4.2.2  Virtual  Sensors 

Engine  Health  Monitoring  (EHM)  systems  prefer  as  much  directly  sensed  data  from  the  engine 
as  possible,  without  to  much  redundancy,  so  that  accurate  assessments  associated  with  lifing 
critical  components  or  diagnosing  faults  can  be  accomplished  quickly  and  with  a  high  degree 
of  confidence.  However,  due  to  the  limited  amount  of  directly  sensed  parameters  on  many 
engines  (resulting  from  either  technology  deficiencies  or  simply  engine  vintage)  crude 
estimates  are  often  made  for  important  lifing  parameters  such  as  the  turbine  inlet  temperature, 
etc.  To  solve  this  problem,  “virtual  sensors”  were  developed  during  this  program  that  were 
capable  of  accurately  estimating  unmeasured  parameters  in  real-time.  In  particular,  the  stator 
outlet  temperature  (SOT),  mass  flow  (Wla),  fan  and  compressor  delivery  temperature  (T3), 
and  turbine  inlet  temperature  (T4)  were  all  estimated  in  real-time  utilizing  a  polynomial  neural 
networks  that  were  trained  from  the  engine  gas  synthesis  model.  The  results  from  the  real¬ 
time  neural  network  estimates  as  comparred  to  empirical  based  polynomial  models  are  shown 
in  Figures  9-12.  In  all  cases,  the  neural  network  estimates  were  considered  more  accurate 
than  the  existing  empirical  polynomial  fitted  equations.  In  the  case  of  estimating  SOT,  the 
empirical  method  was  inaccurate  by  as  much  as  10%,  while  the  neural  network  estimates  were 
within  1  % .  An  order  of  magnitude  increase  in  accuracy. 
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Comparison  of  SOT  Estimates 
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Comparison  of  T4  Estimates 
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Comparison  of  W1A  Estimates 


Figure  11 


Comparison  of  T3  Estimates 
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Figure  12 


4.2.3  Long  Term  Trending  Analysis 


In  an  operational  EHM  system,  data  will  be  recorded  at  specific  points  during  each  flight,  and 
the  trending  of  these  “consistent”  data  points  observed  over  time.  Ideally,  an  identical  flight 
point  or  points  and  engine  conditions  would  be  used  for  each  flight,  but  this  is  clearly 
impractical.  Hence,  for  the  purposes  of  this  EHM  system,  weight  off  wheels  (WOW)  during 
take-off  will  be  used  to  simulate  a  “common”  engine  condition. 

The  trend  parameters  chosen  for  this  EHM  system  were  based  on  “typical”  non-dimensional 
parameter  ratios  that  propulsion  engineers  look  at  if  they  suspect  engine  problems.  The  non- 
dimensional  trending  parameters  are  NL /V®,  T2/T1,  P3/P1,  T6/T1,  and  Wf/8V©,  all 
corrected  to  an  NH/V©  of  97.5%.  If  the  fleet  of  engines  were  to  behave  truly  non- 
dimensionally,  there  would  be  unique  relationships  between  the  non-dimensional  groups. 
However,  Reynold’s  number  effects,  variations  in  engine  operating  parameters,  etc.  introduce 
some  variability  in  this  process.  Therefore,  it  is  necessary  to  make  trend  comparisons  at 
similar  flight  conditions  and  engine  ratings  to  minimize  the  impact  of  these  effects. 

The  non-dimensional  trend  parameters  are  calculated  as  follows: 

1.  Record  the  values  of  NH,  NL,  T2,  P3,  Tl,  PI,  T6,  Wf  at  the  end  of  takeoff  run. 

2.  Calculate:  NH/V©  =  NH/V©(1  +  (2.00xl0'4(Tl-288))) 

3.0  =  Tl/288.15,  6  =  Pl/14.696,  C=Fuel  Calorific  Value  «  10305  (CHU/lb) 

4.  NL H®  =  NL/V©(1  +  (2.346x1 O^T 1-288)))  -  2.34635(NH/V©  -  97.5) 

5.  T2/T1  =  T2/T1  -  0.018954(NH/V©  -  97.5) 

6.  P3/P1  =  P3/P1  -  0.349522(NH/V©  -  97.5) 

7.  T6/T1  =  T6/T1(1  =  (2.378xl0-4(Tl-288)))  -  0.083489(NH/V©  -  97.5) 

8.  Wf/(8V©)  =  Wf/(8V©)  x  (1  +  (4.255x10'4(T1-288)))  -  0.931637(NH/V©  -  97.5) 

4.2.4  General  Alarm  Queue 

All  warnings  and  alarms  detected  by  the  EHM  system  will  automatically  be  displayed  and 
logged  in  the  alarm  queue  provided  in  the  “main  screen”  of  the  EHM  program.  This  includes 
sensor  validation,  performance  and  vibration  anomaly  detection,  performance  and  vibration 
diagnostic  results,  and  unusually  high  consumption  of  component  life.  A  pictorial  version  of 
the  engine  illustrating  the  principle  modular  sections  is  also  displayed  that  changes  color  based 
on  the  warning  or  alarms  that  are  detected.  For  example,  if  a  P3  sensor  is  just  beginning  to 
malfunction,  the  HP  compressor  section  of  the  engine  pictorial  is  turned  yellow,  indicating  a 
warning  associated  with  that  part  of  the  engine.  A  complete  description  of  the  cause  of  the 
warning  is  given  in  the  alarm  queue  text  area.  Once  a  fault  goes  beyond  the  warning  stage,  as 
determined  by  the  EHM  sysyetm,  the  engine  pictorial  section  turns  red,  indicating  an  alarm 
status  for  that  section  of  the  engine.  An  example  of  the  EHM  “main  screen”  indicating  an 
alarm  associated  with  the  P3  sensor  is  given  below. 
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Figure  13  EHM  “Main  Screen”  with  P3  Sensor  Problem 
4.3  Health  Module 

The  Health  Module  is  dedicated  to  examining  the  real-time  engine  parameter  data  set  and 
detecting  any  engine  anomalies  that  exist  with  respect  to  the  “normal”  engine’s  operating 
signatures.  This  function  is  performed  for  both  the  performance  parameters  and  vibration 
data.  First,  the  measured  performance  parameters  are  examined  within  pre-determined  speed 
bands  during  the  entire  mission  to  ensure  consistent  and  accurate  performance  patterns  scans. 
When  a  set  of  acquired  engine  performance  parameters  trigger  an  anomaly  being  detected,  the 
current  real-time  performance  data  is  forwarded  to  the  diagnostic  module  for  detailed 
examination.  Based  on  the  trended  data  and  fault  pattern  recognized,  the  severity  and  duration 
of  the  recognized  fault  can  be  determined. 

4.3.1  Performance  Anomaly  Detection 

Engine  performance  anomalies  are  detected  by  comparing  “normal”  engine  signatures  with  a 
set  of  current  measured  engine  data.  Normal  engine  signatures  are  obtained  for  each  engine 
during  the  standard  production  pass-off  tests.  Each  measured  parameter  (Tl,  PI,  T2,  P3,  T6, 
Wf,  NL,  NH)  on  the  engine  is  plotted  against  the  HP  rotor  speed  to  yield  a  “normal”  range  of 
operation  for  that  specific  engine.  Any  deviations  from  the  engine  specific  “fuzzy”  bands 
encompassing  these  parameter  signatures  will  trigger  the  anomaly  detection  routines.  The 
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T6  Actual/Deck 


“fuzzy”  bands  are  implemented  with  a  dedicated  fuzzy  logic  routine  that  contains  membership 
functions  that  are  specifically  related  to  the  particular  engine  being  monitored. 

Engine  signature  models  were  necessary  due  to  the  large  degree  of  “scatter”  that  exists 
between  each  similar  type  of  engine  in  a  fleet.  Figure  14  is  a  plot  illustrating  the  “scatter” 
between  20  similar  engines  with  respect  to  the  exhaust  gas  temperature.  Figure  15  shows  four 
plots  of  engine  signatures  for  a  particular  set  of  engine  pass-off  data.  The  best  polynomial  fit 
upto  a  sixth  order  is  used  for  each  measured  parameter  on  the  engine. 
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Figure  14  Engine  “Scatter”  for  Exhaust  Gas  Temperature 
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The  following  series  of  pages  (8  pages  total)  titled  “Fuzzy  Logic  Module  -  performance” 
gives  the  details  associated  with  the  fuzzy  logic  rulebase  and  membership  functions  that  were 
used  in  the  performance  anomaly  detection  submodule  of  the  “Health  Module”.  The  first  page 
of  this  series  shows  a  block  diagram  of  the  module  including  inputs  and  outputs.  The  inputs 
all  designated  as  xx_delta  (where  xx  is  the  sensor  name)  represent  the  difference  between  the 
engine  signature  model  and  the  actual  sensed  data  at  a  particular  speed  (approximate  power 
level).  The  output  is  a  measure  indicating  the  level  of  any  anomaly  that  might  have  occurred. 
The  output  membership  functions  will  classify  this  module  output  as  either  OK,  WARNING, 
or  ALARM,  depending  on  the  observed  differences  between  the  model  and  measurements. 
The  corresponding  membeship  functions  and  rulebase  for  each  of  the  input/output  parameters 
is  also  provided.  Details  describing  the  basics  of  fuzzy  logic  decision  analysis  are  given  in 
Appendix  B. 

4.3.2  Vibration  Anomaly  Detection 

In  addition  to  the  performance  anomaly  detection  described  above,  vibration  anomaly  detection 
and  diagnostics  is  also  performed  within  the  real-time  monitoring  environment.  Vibration 
spectrums  from  the  available  engine  installed  accelerometers  are  gathered  at  particular  engine 
operating  speeds  to  form  a  “current”  database  of  the  engine’s  vibration  characteristics.  The 
speed  ranges  at  which  the  spectrums  are  stored  for  the  F405  engine  are  80%,  85%,  90%, 
95%,  and  100%  maximum  NH  rotor  speed.  Figure  16  is  an  illustration  of  the  vibration 
anomaly  detection  scheme  for  spectrums  gathered  from  the  starboard  tangential  and  port  radial 
accelerometers. 
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Figure  16  Vibration  Diagnostic  Scheme 
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The  fuzzy  logic  based  anomaly  detection  utilized  the  shaft  speed  tracked  orders,  other 
identified  vibration  peaks  (synchronous  and  non-synchronous),  and  a  broadband  spectral 
density  measure  to  detect  anomaly  levels  as  being  OK,  WARNING,  or  ALARM.  The  data 
analysis  and  preprocessing  that  was  used  to  develop  this  subsystem  were  based  on  over  30 
engines  worth  of  data  with  various  vibration  faults.  Due  to  the  proprietary  nature  of  this  data, 
the  vibration  fault  and  normal  spectrums  can  not  be  included  in  this  report. 

As  in  the  case  for  the  performance  anomaly  detection,  the  following  series  of  7  pages  with 
“VTB_DET.PRJ”  on  the  bottom  of  the  pages,  gives  the  details  associated  with  the  fuzzy  logic 
rulebase  and  membership  functions  that  were  used  in  the  vibration  anomaly  detection 
submodule  of  the  “Health  Module”.  The  first  page  of  this  series  shows  a  block  diagram  of  the 
module  including  inputs  and  outputs.  The  inputs  designated  as  nhjpeak,  nl_peak,  peak_3,  and 
b-band  represent  the  spectral  amplitudes  at  the  particular  frequencies  as  defined  by  NH  (HP 
shaft  speed),  NL  (LP  shaft  speed),  peak_3  being  the  next  highest  peak,  and  b_band 
representing  the  broadband  spectral  density.  The  output  is  a  measure  indicating  the  level  of 
any  anomaly  that  might  have  occurred.  The  output  membership  functions  will  classify  this 
module  output  as  either  OK,  WARNING,  or  ALARM,  depending  on  the  observed  spectral 
amplitudes.  The  corresponding  membeship  functions  and  rulebase  for  each  of  the  input/output 
parameters  is  again  provided. 


4.4  Diagnostic  Module 

Once  an  anomaly  is  detected  and  the  current  data  is  transferred  to  the  Diagnostic  Module, 
dedicated  neural  network  fault  classifiers  determine  the  probable  cause  of  the  fault  or  degraded 
performance. 

4.4.1  Performance  Diagnostics 

A  block  diagram  of  the  performance  diagnostic  procedure  is  given  in  Figure  17  shown  below. 
The  underlying  design  of  this  model-based,  fault  diagnostic  module  lies  in  the  determination  of 
changing  conditions  appearing  in  engine  sensory  data  due  to  the  existence  of  particular  faults. 
These  observed  changes  are  compared  with  the  "normal"  operating  engine  process  to 
recognize  error  residuals.  These  residuals  and  associated  patterns  are  then  analyzed  for  failure 
detection  and  diagnosis  by  comparing  them  with  known  failure  signatures  associated  with  a 
failed  component  on  the  operating  engine. 
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Figure  17  Performance  Diagnostic  Scheme 

Engine  fault  signatures,  which  illustrate  the  effect  of  a  failure  on  particular  engine  parameters, 
are  generated  from  both  historical  engine  data  and  engine  synthesis  models  of  the  engine.  In 
fact,  a  combination  of  these  approaches  is  utilized  in  this  EHM  system.  In  the  end,  the  failure 
diagnosis  is  accomplished  with  a  neural  network  classifier  to  recognize  the  patterns  of 
respective  failure  signatures.  The  performance  diagnostic  module  in  this  program  utilizes  both 
self  organizing  neural  network  maps  (to  cluster  and  identify  similar  patterns)  and  trained 
network  classifiers  for  specific  problem  diagnosis  (Kohonen,  1987). 

The  real-time  engine  data  for  a  particular  speed-band  is  first  compared  with  the  corresponding 
“normal”  operating  patterns  to  determine  measured  parameter  changes.  These  error  patterns 
are  then  normalized  with  respect  to  the  maximum  measured  parameter  change  and  passed  to  a 
self  organizing  neural  network  map  (Kohonen  network)  for  initial  pattern  clustering.  Figure 
18  illustrates  the  results  of  Kohonen  self-organizing  map  under  noisy  pattern  conditions.  Error 
pattern  clustering  was  used  as  an  initial  diagnostic  step  because  of  its  high  robustness  with 
respect  to  pattern  noise.  After  the  error  pattern  has  been  organized  into  a  particular  location 
on  10x10  interpretive  Kohonen  map,  a  trained  back-propagation  network  classifies  the 
coordinate  location  on  the  map  into  a  specific  diagnosis. 
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Figure  18  Kohonen  Self-Organizing  Map  Diagnostics 

The  performanc  diagnostic  module  dedicated  to  identifying  particular  performance  degradation 
patterns  in  the  engine  has  been  trained  to  recognize  the  following  abnormal  engine  conditions. 

1 .  Inner  fan  efficiency  drop 

2.  HP  compressor  efficiency  drop 

3.  HP  turbine  efficiency  drop 

4.  HP  compressor  capacity  drop 

5.  HP  compressor  capacity  rise 

6.  HP  turbine  capacity  drop 

7.  LP  turbine  capacity  drop 

8.  LP  turbine  capacity  rise 

9.  HP  system  bleed  off 

10.  LP  system  bleed  off 


Table  2  illustrates  the  results  of  the  SOM  neural  network  for  recognizing  performance 
degradation  patterns  with  30%  noise  added  to  them.  The  matrix-type  table  would  be  an  identity 
matrix  if  the  particular  performance  degradation  patterns  were  recognized  perfectly.  One  example 
of  each  performance  degradation  pattern  is  given  in  Table  2,  but  hundred  of  test  cases  provided 
similar  results,  shown  the  networks  robustness  to  noise.  The  pattern  numbers  in  the  top  row 
correspond  to  the  pattern  faults  and  numbers  given  above. 
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Table  2  SOM  Neural  Network  Results  for  Performance  Degradation 


Fault# 

i 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

case  1 

0.98 

-0.12 

0.01 

0.03 

-0.12 

-0.01 

0.03 

-0.11 

-0.12 

-0.09 

-0.07 

case  2 

-0.11 

1.03 

-0.04 

-0.12 

-0.12 

0.03 

-0.13 

-0.07 

-0.12 

-0.05 

-0.10 

case  3 

0.04 

0.03 

1.00 

-0.13 

-0.11 

0.06 

0.02 

-0.13 

-0.11 

-0.12 

-0.12 

case  4 

-0.04 

-0.12 

-0.12 

0.90 

-0.05 

-0.11 

-0.03 

-0.04 

-0.01 

0.00 

0.01 

case  5 

-0.12 

0.04 

-0.12 

0.01 

1.00 

-0.03 

-0.12 

0.04 

-0.03 

-0.01 

-0.12 

case  6 

-0.12 

-0.12 

-0.13 

-0.12 

0.01 

0.98 

0.05 

-0.11 

-0.02 

0.00 

-0.11 

case  7 

-0.05 

-0.12 

0.01 

-0.11 

-0.12 

-0.02 

0.97 

-0.10 

-0.13 

0.00 

-0.12 

case  8 

-0.12 

0.04 

-0.12 

-0.02 

0.08 

-0.09 

-0.06 

0.80 

0.03 

-0.04 

-0.12 

case  9 

-0.13 

-0.12 

-0.12 

-0.10 

0.05 

0.00 

-0.05 

0.03 

0.98 

0.00 

-0.02 

case  10 

0.02 

0.00 

-0.11 

-0.01 

-0.12 

-0.02 

0.02 

-0.04 

-0.11 

0.98 

-0.01 

case  11 

0.00 

0.01 

0.02 

-0.09 

-0.12 

-0.01 

0.00 

-0.08 

0.02 

0.04 

1.01 

4.4.2  Vibration  Diagnostics 

A  block  diagram  of  the  vibration  diagnostic  procedure  is  given  in  Figure  19  shown  below. 
Refering  to  Figure  19,  once  the  acceleration  power  spectral  densities  are  organized  into  their 
respective  bins,  the  peaks  of  the  NL  and  NH  rotor  speeds  are  examined  for  overall  amplitude 
and  location  (in  terms  of  the  %  max  NH  speed)  of  the  peaks.  This  information  is  used  by  the 
fuzzy  logic  diagnostic  algorithms  to  determine  if  the  vibration  is  coming  from  either  the 
compressor  or  turbine  and  if  it  is  associated  with  the  HP  or  LP  shaft.  Once  the  basic  location 
of  the  vibration  source  is  determined,  a  more  detailed  diagnosis  of  the  vibration  problem  is 
predicted.  Currently,  the  system  has  been  trained  to  recognize  vibration  fault  patterns 
including;  1.)  Unbalance/Misalignment,  2.)  Rotor  Rub  and  Mechanical  Looseness,  and  3.) 
Deteriorated  Bearing  Conditions.  Due  to  the  Rolls-Royce  proprietary  nature  of  the  algorithms 
used  in  diagnosing  vibration  faults,  the  specific  rulebase  for  vibration  diagnosis  can  not  be 
included  in  this  report. 


4.5  Engine  Life  Module 

During  the  mission,  data  from  the  engine  duty  monitor  within  the  Data  Management  Module  is 
continuously  being  transferred  to  the  Engine  Life  Module  so  that  "mission  representative"  life 
may  be  accumulated.  The  life  accumulation  algorithm  will  include  the  engine  specific 
parameters  tracked  throughout  the  entire  mission.  Hot  section  temperatures  will  be  estimated 
in  real-time  based  on  a  neural  network  architecture  trained  from  engine  synthesis  models. 
Figure  20  is  an  illustration  of  the  module  functionality.  Corresponding  material  creep  and 
thermo-mechanical  fatigue  will  therefore  be  more  accurately  determined  based  on  actual 
mission  severity.  At  the  end  of  the  mission,  critical  component  life  accumulated  during  that 
mission  is  reported  and  transferred  back  to  the  data  management  module  for  overall 
accumulation  of  each  components  life  usage. 
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Figure  20  Engine  Life  Scheme 

A  principal  advantage  of  integrating  engine  life  usage  with  real-time  engine  diagnostics  is  that  they 
both  utilize  the  same  engine  data.  Incorporating  a  more  comprehensive  set  of  engine  parameters 
into  component  life  accumulation  algorithms  will  have  a  major  impact  on  maximizing  engine 
operational  life  without  jeopardizing  flight  safety. 

The  described  EHM  system  incorporates  LCF,  material  temperature/creep,  and  thermo¬ 
mechanical  fatigue  aspects  into  a  comprehensive  damage  accumulation  algorithm.  This  represents 
a  significant  enhancement  over  the  current  life  monitoring  systems.  Primarily,  increased  emphasis 
wiD  be  placed  on  “hot”  components  where  these  mechanisms  play  a  large  role  in  the  failure 
process.  The  proposed  approach  of  individually  tracking  the  total  life  of  each  critical  component 
will  allow  for  a  more  representative  and  less  conservative  estimate  of  component  life 
consumption. 

The  engine  life  module  discussed  in  this  paper  concentrates  on  the  HP  turbme  disk  and  Wades. 
Other  components  can  easily  be  added  to  the  system  if  the  necessary  life  algorithms  are  available. 
Engine  life  usage  algorithms  for  creep  and  low  cycle  fatigue  of  critical  parts  are  already  included 
in  the  Aircraft  Data  Recording  system  on  the  T45  A  Goshawk  aircraft.  The  algorithms  for  the  HP 
disk  will  be  refined  to  use  the  more  specific  data  available  from  the  Data  Management  module  to 
record  accumulated  life  usage. 
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5.0  EHM  System  Testing  and  Results 

5.1  Objective  of  Ground  Tests 

The  primary  objective  of  the  Engine  Health  Monitoring  (EHM)  system  ground  tests  was  to 
demonstrate  the  advanced,  real-time  monitoring,  diagnostic  and  component  lifing  capabilities 
under  actual  engine  operating  conditions.  Within  this  SBIR  program,  the  EHM  system  has 
undergone  successful  ground  tests  on  three  (3)  different  Rolls-Royce  Adour  engines  (Navy 
F405)  in  Bristol,  England.  The  EHM  system,  developed  as  a  Windows  NT  application 
program  with  user-friendly  GUI’s,  performed  the  following  functions  during  the  three  ground 
tests;  1.)  real-time  data  acquisition  of  engine  performance  and  vibration  data,  2.)  performance 
and  vibration  anomaly  detection  and  diagnostics,  3.)  critical  component  life  accumulation,  4.) 
sensor  validation,  5.)  virtually  sensed  unmeasured  parameters,  6.)  advanced  short  and  long 
term  trending,  and  6.)  engine  “signature”  based  performance  degradation  monitoring. 

Advanced  fault  classification  techniques  including  standard  back-propagation  neural  networks, 
self-organizing  map  “clustering”  networks,  fuzzy  logic  decision  analysis,  and  polynomial 
networks  were  trained  from  existing  engine  databases  and  gas  path  analysis  (GPA)  models  to 
identify  engine  fault  conditions.  During  the  series  of  ground  tests,  a  total  of  three  different 
actual  engine  sensor  anomalies  were  detected  and  diagnosed  as  well  as  some  additional 
“seeded”  faults  that  were  also  diagnosed.  In  particular,  the  T2  (LP  compressor  delivery 
temperature)  and  WF  (fuel  flow)  test  cell  transducers  both  malfunctioned  during  the  first 
engine  test,  both  of  which  were  detected  and  correctly  diagnosed  in  real-time.  In  addition,  an 
HP  and  LP  shaft  vibration  anomaly  was  also  diagnosed  during  the  first  two  engine  tests. 
Specific  details  associated  with  each  engine  test  are  described  below.  Overall,  Rolls  Royce 
engineers  were  extremely  pleased  with  the  operation  of  the  automatic  EHM  system  and  are 
currently  working  with  Stress  Technology  to  advance  the  developments  of  the  EHM  system 
for  use  at  Rolls  Royce.  The  success  of  the  EHM  system  ground  testing  can  be  summarized  by 
the  following  quote  that  was  made  in  a  letter  to  STI  from  the  Rolls  Royce  engineers: 

“This  is  a  new  and  probably  first  application  of  artificial  intelligence  techniques  in  a  real¬ 
time,  on-board  engine  monitoring  system  having  the  ability  for  diagnosing  vibration, 
performance,  and  component  life  anomalies  concurrently.  Rolls  Royce  commends  STI  for 
the  successful  demonstration  of  this  novel  system.  ” 

H.  R.  Carr  and  R.  G.  Fox,  Rolls  Royce,  pic. 

Significant  technical  accomplishments  of  the  EHM  system  that  were  demonstrated  during  the 
three  engine  tests  are  described  below. 

1.  Integration  of  neural  networks  (unsupervised  and  supervised)  and  fuzzy-logic  to  identify 
engine  anomalies,  both  performance  and  mechanical  (vibration)  related,  and  in  turn 
provide  specific  diagnostics  related  to  the  identified  fault  in  real-time. 
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2.  Capability  to  provide  real-time  estimates  of  the  life  being  consumed  from  critical  engine 
components  including  HP  turbine  blades  and  disks.  Virtually  sensed  turbine  inlet 
temperatures,  mass  flow,  etc.  (currently  not  measured)  are  utilized  to  improve  accuracy  of 
the  actual  life  being  accumulated. 

3.  Advanced  vibration  diagnostics  that  is  based  on  feature  extraction  from  both  spectral 
“waterfall”  plots  and  tracked-order  amplitudes.  The  results  are  passed  through  a  fuzzy- 
logic  decision  analysis  procedure  for  classifying  mechanical  engine  faults. 

4.  Engine  “signature”  based  performance  degradation  monitoring  that  accounts  for  steady- 
state  and  pseudo  steady-state  engine  operation.  Self  organizing  maps  cluster  performance 
faults  with  high  degree  of  robustness  with  respect  to  pattern  uncertainties. 

5.  Real-time  sensor  validation  networks  trained  from  “fleet-wide”  engine  test  data  taken 
during  a  wide  range  of  engine  operating  conditions.  Polynomial  networks  are  implemented 
to  recognize  the  non-linear  relationships  among  the  measured  parameters. 

5.2  Ground  Test  Results 

The  EHM  system  ground  tests  were  performed  at  the  Rolls-Royce  MAEL  test  cells  in  Bristol, 
England.  The  EHM  system’s  capabilities  were  tested  thoroughly  during  each  of  the  three  engine 
tests  with  actual  faults  being  diagnosed  from  test  cell  sensor  faults  and  vibration  signal 
calibration  problems.  In  addition,  sensor  signal  faults  were  purposely  “seeded”  to  better  assess 
the  capability  of  the  EHM  sensor  validation  module.  A  sample  of  the  actual  ground  test  data 
acquired  during  the  tests  is  used  in  the  demonstration  program  included  as  part  of  this  final 
report.  The  demonstrations  are  described  in  more  detail  in  Section  6  of  this  report. 

Test  Cell  Instrumentation  and  Calibration 


Prior  to  the  first  engine  test,  several  system  implementation  and  integration  checkouts  needed  to 
be  performed  on  the  EHM  system.  These  checkouts  included  synchronization  of  the  vibration 
and  performance  data  acquisition  systems,  test  cell  transducer  calibration,  and  frequency  to 
voltage  conversion  of  shaft  speed  tachometers  and  fuel  flow  signals.  Transducer  calibration  was 
performed  by  both  Rolls  Royce  test  engineers  and  the  STI  team.  This  process  included  relating 
an  arbitrary  reference  voltage  from  0-1 0V  to  the  maximum  value  a  particular  transducer  can 
reach  during  a  test.  This  ensured  that  the  data  acquisition  card  would  never  receive  any  voltages 
above  the  10V  operating  range  of  the  A/D  card.  The  specific  calibration  factors  used  for  all  three 
engine  tests  are  shown  below: 


Test  Cell  Calibration  Voltages 


NH  4.63V  =  100%  Max  NH 
T1  1.40V  =  14  degrees  C 
T2  3.25V  =  200  degrees  C 
T6  4.12V  =  1000  degrees  C 


NL  4.42V  =  1 00%  Max  NL 

PI  1.40V  =  14  PSIA 

P3  2.51V  =  250  PSIA 

Wf  3.79V  =  5420  lbm/hr 


33 


Two  separate  data  acquisition  systems  were  required  by  the  EHM  system  to  perform  both 
performance  and  vibration  related  diagnosis  and  component  lifing.  This  was  primarily  due  to  the 
fact  that  the  Rolls  Royce  MAEL  test  cells  had  separate  instrumentation  hardware  for  each.  The 
performance  parameters  including  NH,  NL,  Tl,  PI,  T2,  P3,  T6,  and  Wf  were  acquired  using  a 
standard  16-channel,  parallel  port  data  acquisition  card  manufactured  by  National  Instruments, 
Inc.  The  vibration  data  acquisition  was  performed  with  a  customized,  test  cell  vibration 
diagnostic  system  developed  by  Rolls  Royce  referred  to  as  DEVS  (Diagnostic  Engine  Vibration 
System).  The  EHM  system  directly  interfaced  with  this  DEVS  system  during  the  ground  testing 
through  a  standard  serial  port  connection.  Special  software  was  developed  to  synchronize  the 
two  data  acquisition  systems  for  real-time  operation. 

A  differential  signal  grounding  configuration  was  utilized  for  the  performance  parameter  data 
acquisition  system.  A  differential  signal  is  one  in  which  each  analog  input  signal  has  its  own 
reference  signal  or  signal  return  path.  Differential  input  connections  are  typically  used  in 
situations  were  low  level  voltages  are  being  acquired,  connecting  leads  are  greater  than  10  ft., 
and  signals  travel  through  noisy  environments.  In  general,  differential  signal  connections  reduce 
picked-up  noise,  increase  common-mode  noise  rejection,  and  allow  input  signals  to  float  within 
the  common  mode  limits  of  the  PGIA  (programmable  gain  input  amplifier).  Figure  20  is  an 
illustration  of  the  differential  signal  connections  that  were  used  during  the  engine  ground  testing. 


Figure  20  Differential  Input  Connections 
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Engine  #1  Test 


Engine  Serial  #:  9105 


Date:  10/21/97 


The  EHM  system  was  specifically  developed  to  undergo  an  initial  engine  “training”  period, 
where  the  EHM  system  monitors  and  records  the  “normal”  engine  operating  “signatures”  during 
steady-state  and  pseudo  steady-state  engine  operating  conditions  for  the  full  range  of  engine 
speeds/power.  From  this  recorded  engine  data,  a  series  of  engine  “signature”  models  are 
developed  from  which  the  engine  performance  anomaly  detection  algorithms  are  based.  For  the 
first  engine  test,  the  STI  team  was  only  able  to  perform  initial  engine  “training”  from  a  partial 
engine  accel/decel.  This  was  due  to  the  fact  that  the  engine  in  the  test  cell  had  already  gone 
through  most  of  the  standard  tests  for  production  “pass-off’  testing  and  repeating  engine  runs 
would  put  additional  engine  operating  hours  that  would  be  considered  undesirable.  However,  a 
working  set  of  engine  signature  models  was  still  able  to  be  developed  from  this  partial  ramp- 
up/down  engine  run  and  utilized  in  the  EHM  system  during  the  remaining  few  engine  runs. 

Ideally,  a  complete  training  database  would  need  to  be  constructed  during  an  initial  monitoring 
phase  of  the  engine  over  a  period  of  a  couple  weeks.  Having  such  a  complete  engine  database, 
engine  performance  anomaly  detection  can  be  performed  more  accurately  because  the  effects  of 
engine  non  steady-state  operating  conditions  can  be  “filtered  out”  properly.  This  of  course 
means  that  engine  performance  degradation  monitoring  will  not  be  assessed  by  the  EHM  system 
during  engine  transient  conditions.  This  is  a  reasonable  assumption  because  trying  to  detect 
minor  engine  efficiency  or  capacity  changes  during  engine  transients  would  be  enormously 
difficult  and  too  dependent  on  outside  factors.  However,  all  other  aspects  of  the  EHM  system 
including  sensor  validation,  vibration  anomaly  detection  and  diagnostics,  and  component  lifing 
are  still  being  performed  continuously  and  during  engine  transient  conditions. 

Following  the  engine  vibration  sensor  check-out  run  (partial  ramp  up/down),  the  engine 
underwent  a  “slow”  accel/decel  at  a  rate  of  approximately  2  minutes  for  the  entire  ramp  up/down 
engine  run.  During  this  test,  the  EHM  system  performed  very  well  considering  the  approximate 
nature  of  the  engine  “signature”  models  developed.  In  fact,  three  actual  engine/sensor  faults 
were  identified  in  real-time  by  the  EHM  system.  First,  a  malfunctioning  Wf  (fuel  flow)  sensor 
was  diagnosed  by  the  sensor  validation  module  due  to  “phantom”  fuel  flow  spikes  occurring  at 
100%  NH.  Next,  a  fluctuating  T2  (LP/HP  compressor  temperature)  sensor  was  identified  in  the 
performance  anomaly  detection  module  due  to  test  cell  hardware  “electronic  noise”.  And  finally, 
a  vibration  fault  was  identified  by  the  vibration  anomaly  detection  module  and  further  diagnosed 
as  an  “HP  stub-shaft  out  of  balance”  by  the  vibration  diagnostic  module.  All  three  (3)  of  these 
faults  were  identified  during  the  real-time  operation  of  the  engine. 

Based  on  the  real-time  diagnostic  results  from  this  first  test,  both  the  fuel  flow  sensor  (Wf)  and 
HP/LP  compressor  thermocouple  (T2)  were  examined  by  the  Rolls  Royce  test  engineers.  The 
fuel  flow  sensor  malfunction  was  identified  as  an  intermittent  electronic  hardware  problem  and 
fixed  prior  to  the  next  engine  test  by  replacing  the  existing  hardware  with  properly  working  set  of 
electronics.  However,  the  root  cause  of  the  T2  sensor  fluctuations  identified  within  the  EHM 
system  was  not  fixed  until  some  “in-situ”  testing  was  performed  during  the  second  engine  test. 
The  T2  sensor  fluctuations  turned  out  to  be  related  to  a  grounding  problem  with  the  T2  sensor 
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electronics  and  was  temporarily  fixed  by  placing  a  47  pF  capacitor  in  parallel  with  the  T2  analog 
input  signal  to  “smooth”  it  out.  The  engine  vibration  fault  that  was  detected  during  the  test 
resulted  from  improper  calibration  of  the  accelerometer’s  amplitude  response.  More  specifically, 
the  EHM  system  vibration  diagnostic  module  was  “trained”  based  on  RMS  acceleration 
amplitudes,  (0.707  times  the  peak  acceleration  amplitude),  but  instead,  the  EHM  system  was 
measuring  (receiving)  the  peak-to-peak  acceleration  values.  This  would  mean  that  a  measured 
value  of  2  in/sec  should  have  really  have  only  been  an  RMS  value  of  0.707.  Therefore,  the 
EHM  system  detected  and  correctly  diagnosed  HP  shaft  order  vibration  faults,  even  though  they 
really  didn’t  exist  but  were  perceived  to  have  existed  because  of  the  sensor  calibration  problem. 

The  first  set  of  five  (5)  figures  (Figures  21-25)  labeled  “Engine  Test  #1”,  illustrate  the  measured 
engine  test  data  that  was  acquired  during  the  first  test  as  compared  with  the  “engine  signature” 
models.  Due  to  the  limited  (single  engine  ramp  up/down)  amount  of  engine  training  data  that 
was  recorded  for  this  engine,  the  engine  signature  models  predicted  the  engines  response 
accurately  from  75%  NH  up  to  about  95%  NH  for  both  the  T2  and  T6  thermocouples.  However, 
even  with  limited  training  data,  the  engine  signature  models  for  the  remaining  sensors  were  very 
good,  resulting  in  predicted  engine  responses  less  than  1%  of  the  measured  values.  As  illustrated 
in  Figures  21-25,  the  engine  models  only  utilized  data  recorded  for  NH  speeds  greater  than  75% 
Max.  Therefore  the  engine  models  and  corresponding  anomaly  detection/diagnosis  was  only 
operational  above  this  NH  speed.  Figure  23  clearly  illustrates  the  electronic  grounding  problem 
that  was  encountered  with  the  T2  sensor  and  Figure  25  shows  the  WF  fuel  flow  spikes  that 
occurred  when  the  engine  was  near  maximum  speed  and  on  the  ramp  down  portion. 

Engine  #2  Test  Engine  Serial  #:  9106  Date:  10/23/97 

The  second  engine  test  occurred  three  days  following  the  first  test  and  was  scheduled  as  part  of  a 
standard  production  pass-off  test.  During  such  tests,  steady-state  performance  scans  are  typically 
performed  at  1 1  different  speeds,  ranging  from  approximately  55%  NH  Max  (Idle)  to  103%  NH 
Max.  A  profile  of  the  performance  parameter  scans  taken  during  this  test  are  given  in  Figures 
26-30.  The  amount  of  time  taken  for  each  scan  (at  constant  speed)  is  approximately  2  minutes, 
resulting  in  a  total  engine  test  time  of  less  than  30  minutes. 

The  engine  signature  models  for  this  engine  were  developed  from  the  steady-state  performance 
test  scan  data.  Again,  more  data  associated  with  pseudo  steady-state  operating  conditions  would 
have  been  beneficial,  but  this  data  set  was  again  satisfactory  for  testing  the  EHM  system 
capabilities.  As  shown  in  Figure  27,  the  intercompressor  thermocouple  (T2)  sensor  was  fixed 
after  a  couple  minutes  into  the  test’s  performance  scan  data  acquisition.  This  effected  the  engine 
signature  model  associated  with  the  T2  prediction  as  shown  in  the  ramp-down  portion  of  Figure 
27.  However,  the  T2  model  predicted  values  taken  above  the  NH  speed  where  the  T2  sensor  was 
fixed  are  excellent,  with  RMS  errors  between  the  actual  and  predicted  values  of  less  than  1%. 
The  remaining  performance  parameter  predictions  were  all  calculated  within  the  EHM  system’s 
ability  to  diagnose  a  2%  shift  in  either  compressor  or  turbine  efficiency.  In  other  words,  the 
errors  between  the  predicted  and  measured  performance  parameters  must  be  less  than  the 
corresponding  parameter  shift  associated  with  a  2%  efficiency  shift.  This  allows  the  EHM 
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system  to  detect  performance  degradation  shifts  once  they  have  reached  approximately  2%  of  the 
original  engine  signature  baseline. 

During  the  second  test,  the  only  engine  fault  identified  was  a  repeat  of  the  vibration  anomaly  that 
was  detected  in  the  prior  test.  Again,  the  EHM  system  was  developed  to  assess  the  vibration 
spectral  amplitudes  as  being  RMS  values,  but  instead  the  test  cell  was  measuring  and  incorrectly 
passing  to  the  EHM  system  the  peak-to-peak  values.  This  is  equivalent  to  multiplying  the  real 
RMS  value  by  2^2  (or  2.828),  therefore  yielding  a  perceived  vibration  anomaly  that  was  detected 
by  the  system.  Note,  although  the  EHM  system  was  developed  to  accept  data  from  both  the 
starboard  tangential  and  port  radial  accelerometers,  current  F405  production  engines  only  have 
the  starboard  tangential  accelerometer  installed.  Hence,  the  redundancy  (confidence  level)  factor 
and  vibration  diagnostic  capability  for  locating  the  more  precise  source  of  the  vibration  is 
reduced  for  these  engine  configurations. 

Engine  #3  Test  Engine  Serial  #:  9107  Date:  11/18/97 

The  third  engine  tested  as  part  of  this  SBIR  program  occurred  approximately  3  weeks  following 
the  second  engine  test.  This  test  was  similar  in  profile  to  the  second  engine  test  because  it  was 
also  a  production  pass-off  test  where  performance  scans  were  taken  at  1 1  pre-determined  NH 
speeds.  The  performance  scan  data  was  again  used  to  develop  the  engine  signature  models  used 
in  the  performance  anomaly  detection  module.  The  vibration  accelerometer  calibration  factor 
relating  peak-to-peak  amplitudes  to  RMS  amplitudes  was  corrected  during  this  test  so  that  no 
false  vibration  anomalies  were  detected.  In  fact,  no  engine  sensor  or  other  faults  were  detected  at 
all  during  this  test.  Because  of  this,  the  STI  team  decided  to  “seed”  some  sensor  faults  by 
opening  and  shorting  the  sensor  signal  leads  during  engine  operation,  of  course  with  the  consent 
of  the  Rolls  Royce  test  engineers. 

A  set  of  test  data  associated  with  one  of  the  performance  scan  tests  performed  on  this  engine  is 
given  in  Figures  31-35.  Towards  the  end  of  this  test,  the  P3  (compressor  delivery  pressure) 
sensor  was  purposely  shorted  and  the  T2  (intercompressor  temperature)  sensor  purposely  open 
circuited.  This  resulted  in  an  immediate  response  by  the  EHM  system  by  diagnosing  the 
corresponding  sensor  failure  in  both  cases.  In  fact,  the  STI  team  “seeded”  a  sensor  fault  for  each 
of  the  measured  parameters  with  successful  diagnosis  results  being  identified  by  the  EHM 
system  in  each  case. 

The  next  “seeded”  fault  type  scenario  investigated  was  related  to  simultaneous  occurring  sensor 
failures.  In  this  case,  two  different  sensor  lead  wires  were  open  circuited  to  examine  the  EHM 
sensor  validation  module’s  ability  to  diagnose  multiple  sensor  failures  occurring  at  one  time. 
Recall,  that  the  sensor  validation  scheme  with  the  EHM  system  is  based  primarily  on  a  standard 
“feed  forward”  neural  network  architecture  with  back  propagation  of  error  using  during  the 
training.  However,  in  addition  to  the  neural  network,  a  parallel  sensor  validation  check  is 
performed  by  examining  the  difference  between  predicted  and  measured  engine  parameters.  By 
utilizing  this  redundant  architecture,  the  multiple  sensor  faults  were  always  identified  by  the 
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EHM  system,  but  in  some  instances  manifested  themselves  as  only  a  single  sensor  fault.  In 
either  case,  at  least  one  sensor  fault  was  always  identified  for  all  simultaneous  sensor  fault  cases. 

Based  on  the  results  from  each  of  the  three  tests  conducted,  it  was  concluded  that  an  important 
balance  must  exist  between  the  real-time  diagnostic  capabilities  and  the  ability  to  deal  with  “real 
world”  uncertainties  from  sensor  signal  transients,  random  measurement  fluctuations  and  non 
steady-state  performance  and  vibration  parameter  changes.  In  is  recommended  that  this  balance 
be  achieved  through:  1 .)  Intelligent  “engine  specific”  tolerances  built  into  the  EHM  system  and 
2.)  An  engine  signature  approach  to  “normal”  engine  operation  utilizing  probabilistic  engineering 
analysis.  In  order  to  address  these  concerns,  the  tested  EHM  system  is  currently  being  modified 
to  perform  vibration  and  performance  anomaly  detection  with  adaptable  fuzzy-logic  membership 
functions  that  are  adjusted  during  an  initial  EHM  system  installation  period.  Also,  EHM  fault 
pattern  recognition  algorithms  for  vibration  and  performance  related  diagnosis  were  adjusted  to 
perform  selective  averaging  and  trending  over  specific  engine  operating  conditions.  The 
modifications  are  expected  produce  more  robust,  consistent  and  accurate  diagnostic  assessments. 
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6.0  EHM  System  Demonstration  Program 

This  EHM  (engine  health  monitoring)  demonstration  program  was  developed  by  STI  to 
illustrate  the  basic  operation  and  functionality  of  the  real-time  engine  health  monitoring 
system.  The  EHM  software  provides  dedicated  sensor  validation,  long/short  term 
trending,  virtual  sensors,  vibration  and  performanece  anomaly  detection,  vibration  and 
performance  diagnostic  classifiers  and  decision  analysis,  and  critical  component  life  usage 
capabilities  all  in  a  real-time  monitoring  environment.  The  system  has  been  successfully 
ground  tested  on  three  (3)  different  engines  at  the  Rolls-Royce  MAEL  division  in  Bristol, 
England.  Technical  details  describing  the  capabilities  of  the  EHM  system  are  given  in  the 
SBIR  final  report  and  an  ASME  paper  attached  to  the  end  of  the  demonstration  program 
description. 

Minimum  Hardware  Requirements 
This  EHM  demonstration  program  requires: 

•  Intel  Pentium  based  or  better  IBM-compatible  personal  computer 

•  One  of  the  following  operating  systems: 

1 .  Microsoft  Windows  NT  4.0  or  above 

2.  Microsoft  Windows  95 

•  VGA  graphics  card  or  better 

•  8  Mb  of  RAM  minimum,  16  Mb  of  RAM  recommended. 

•  Microsoft  Mouse  or  other  Windows  compatible  device 

•  4  Mb  of  hard  disk  space 

6.1  Installing  EHM  Demo  Software 

The  EHM  demonstration  program  is  a  32-bit  application  designed  for  Windows  NT  or 
Windows  95  operating  systems.  To  install  the  EHM  demo: 

1 .  Start  Windows  NT  or  Windows  95. 

No  other  application  should  be  running  while  EHM  is  being  installed. 

2.  Insert  the  disk  labeled  “EHM  Disk  1  ”  into  your  disk  drive. 

3.  Select  the  “Start”  button  from  the  taskbar  at  the  bottom  of  the  screen  and  then 
“Run...”  when  running  Windows  NT  or  Windows  95. 

The  “Run”  dialog  appears. 

4.  Type  “A:\Setup”  in  the  Command  Line  text  box. 

If  you  are  installing  from  a  drive  other  than  A,  substitute  the  letter  for  the  source  drive. 

5.  Select  “OK”. 
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The  following  welcome  dialog  appears: 


Welcome 


Welcome  to  the  EHM  Setup  program.  This  program 
■*WJ  mI  instal  EHM  on  you  computer. 


It  i*  strong^  recommended  that  you  exit  al  Window*  pro^ams 
before  running  this  Setup  program. 

CSck  Cancel  to  quit  Setup  and  then  dose  any  progams  you 
have  ruming.  CSck  Next  to  conthue  with  the  Setup  program 


WARNING:  This  program  is  protected  by  copyright  law  and 
rtf  emational  treaties. 

Unauthorized  reproduction  or  tfctribution  of  this  program  or  any 
portion  of  it  may  resul  in  severe  crvi  and  criminal  penaties,  and 
wi  be  prosecuted  to  the  maximum  extent  posable  under  law. 


(  ]j»d>  ~==^  Cancel 


6.  Select  “Next”  to  go  to  the  next  screen. 

7.  Change  the  default  name  and  destination  of  the  EHM  directory  If  desired  and 
Select  “Next”. 

The  installation  program  will  then  install  the  program  in  the  specified  directory.  You 
will  be  told  when  to  change  diskettes.  The  installation  program  will  also  add  EHM  to 
the  Program  menu  option  under  the  taskbar  at  the  bottom  of  the  screen. 

8.  To  start  the  EHM  program,  select  the  “Start”  button  from  the  taskbar  at  the 
bottom  of  the  screen,  point  to  EHM,  and  then  select  EHM.  Choose  either 
Demo  from  the  following  Dialog  box. 


6.2  Demonstration  Files 
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Once  you  have  selected  “Demo  1”  from  the  dialog  box  show  above,  the  EHM  system  will 
automatically  begin  operation  as  if  the  EHM  system  was  processing  real-time  data  from  an 
engine.  The  EHM  “main  screen”  shown  below  should  now  be  active  with  the 
instrumentation  panel  changing  with  the  data  that  is  being  received  from  the  demonstration 
file.  The  various  EHM  system  monitoring  and  diagnostic  screens  can  be  accessed  from 
the  top  menu  bar  that  is  organized  with  respect  to  the  different  engineering  modules  that 
comprise  the  EHM  system.  These  include  the,  1.)  Engine  Instrument  Display,  2.)  Data 
Management,  3.)  Health,  4.)  Diagnostic,  and  5.)  Life  modules. 


“Data  Management”  Menu  Bar 

First,  from  the  top  menu  bar,  select  the  “Data  Management”  menu  option.  Contained 
within  this  menu  option  exist  the  “Sensor  Validation”,  “Virtual  Sensor”,  and  the  “Long 
Term  Trend  Plot”  screens.  Select  the  “Sensor  Validation”  option  and  the  screen  shown 
below  titled  “Sensor  Validation  Screen”  will  appear.  In  this  module,  the  measured  data  is 
being  processed  by  a  trained  neural  network  in  real-time  to  assess  if  a  sensor  fault  has 
occurred.  During  this  demonstration,  a  fuel  flow  (WF)  sensor  problem  is  diagnosed  within 
this  module  when  the  NH  speed  approximately  reaches  100%  of  its  rated  maximum  value. 
When  this  fault  is  detected,  the  output  from  the  neural  network  turns  yellow  illustrating 
the  sensor  is  having  a  problem.  The  “Alarm  Queue”  is  then  updated  showing  that  the  fuel 
flow  (WF)  sensor  has  been  diagnosed  with  a  fault.  The  engine  pictorial  also  shows  a 
corresponding  warning  in  the  combustor  area  of  the  engine. 


Sensor  Validation  Screen 


Next,  open  the  “Virtual  Sensor”  screen  shown  below.  This  option  displays  the  real-time, 
engine  parameter  estimates  that  are  being  predicted  through  the  trained  neural  network. 
Specifically,  the  neural  network  (trained  by  an  engine  GPA  model)  is  estimating  in  real¬ 
time  important  engine  parameters  that  are  currently  not  measured  on  the  Navy  F405 
engine.  The  virtually  sensed  parameters  include,  1.)  Stator  Outlet  Temperature  (SOT),  2.) 
Compressor  delivery  temperature  (T3),  3.)  Turbine  Inlet  Temperature  (T4),  and  4.)  Gas 
Mass  Row.  The  significance  of  this  technique  is  that  the  SOT  and  T4  virtual  sensors 
provide  accurate,  real-time  information  that  is  critical  to  estimating  remaining  life 
associated  with  the  HP  turbine  blades  and  disk. 


Virtual  Sensor  Screen 


The  last  option  to  be  opened  from  the  “Data  Management”  menu  bar  is  called  “Long  Term 
Trend  Plot”.  This  option  displays  a  plot  of  important,  non-dimensional,  long  term  engine 
parameter  trends.  The  non-dimensional  trending  parameters,  TP1  through  TP5,  are 
NL/V0,  T2/T1,  P3/P1,  T6/T1,  and  Wfl8V0,  respectively,  ah  corrected  to  an  NH/V0  of 


97  5%  The  “Long  Term  Trend  Plot”  screen  is  shown  below.  Note,  the  only  data  point 
taken  per  flight  is  calculated  form  the  measured  parameters  recorded  at  weight  off  wheels 
(WOW).  For  this  demonstration,  the  WOW  flight  point  is  taken  the  first  time  a  c 

value  is  reached. 


“Health”  Menu  Bar 

The  next  set  of  EHM  diagnostic  screens  to  be  examined  are  part  of  the  “Health”  module 
menu  options.  There  are  two  primary  EHM  health  screens  within  this  menu,  they  are  the 
“Performance  Health”  and  “Vibration  Health”  screens.  The  “Vibration  Health  portion  is 
broken  up  into  the  “Starboard  Tangential”  and  “Port  Radial”  accelerometer  response 
screens.  Only  the  “Starboard  Tangential”  screen  is  currently  active  in  this  demonstration 
because  it  is  the  only  accelerometer  on  the  F405  production  engine. 

First,  let’s  examine  the  “Performance  Health”  screen.  This  screen  basically  compares  the 
difference  between  the  measured  engine  parameters  and  those  predicted  by  die  engine 
signature  models.  When  a  parameter  starts  to  “drift”  outside  the  predetermined  fuzzy 
logic  based  membership  function  “bands”,  an  anomaly  is  detected  and  sent  to  the  a  arm 

oueue  The  “Performance  Health”  screen  is  shown  below.  The  Demo  1  demonstration  file 

produces  a  performance  anomaly  with  reject  to  the  T2  sensor.  This  was  due  to  the  fact 
that  the  sensor  was  producing  small  fluctuations  not  large  enough  to  “flag  it  as  a  sensor 

problem. 


“Preformance  Health”  Screen 


Next,  open  the  “Starboard  Tangential”  submenu  selection  under  the  “Vibration  Health” 
menu  item.  In  this  screen,  the  four  most  significant  features  associated  with  the  vibration 
spectral  densities  are  used  as  input  to  a  fuzzy  logic  based  anomaly  detection  algorithm. 
The  four  primary  features  include  the  NH  and  NL  shaft  speed  tracked-order  amplitudes, 
the  maximum  peak  that  is  not  related  to  NH  or  NL,  and  a  broadband  measure  of  the  entire 
spectral  density.  Based  on  the  value  of  these  features  and  an  extensive  knowledge  base 
consisting  of  “normal”  and  “abnormal”  vibration  spectrums,  vibration  anomalies  are 
detected.  The  “Starboard  Tangential”  and  ‘Tort  Radial”  vibration  health  screens  are 
shown  below.  HP  and  LP  peaks  cause  anomaly  alarms  to  trigger  in  this  Demol  file. 


“Vibration  Health”  Screens 


“Diagnostic”  Menu  Bar 


When  a  vibration  or  performance  anomaly  is  detected,  the  current  set  of  measured  data  is 
passed  to  the  corresponding  Diagnostic  module.  The  Performance  Diagnostic  module  is 
shown  below.  Within  this  module,  performance  degradation  fault  patterns  are  assessed  to 
determine  the  likely  cause  and  general  location  within  the  engine  of  the  detected 
performance  anomaly.  Averaging  and  long  term  trending  of  the  performance  degradation 
patterns  is  necessary  to  for  accurate  diagnostic  results.  Also  within  this  screen,  the 
diagnosed  faults  are  rated  in  terms  of  confidence  of  a  correct  diagnosis  and  severity  of  the 
fault. 

This  demonstration  file  did  not  have  any  performance  degradation  fault  patterns  diagnosed 
as  a  particular  fault.  Afterall,  the  tests  were  performed  on  new  production  engines. 
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Performance  Diagnostics  Screen 


The  Vibration  Diagnostic  module  utilizes  the  results  from  the  anaomaly  detector  feature 
extration  process,  tracked-order  amplitudes  at  different  speeds,  and  an  engine  vibration 
database  to  diagnose  specific  vibration  problems  typical  for  the  engine  being  monitored. 
The  corresponding  EHM  screen  is  shown  below.  At  the  top  of  this  screen  the  engine 
tracked-order  vibration  amplitudes  are  calculated,  averaged,  and  placed  in  respective 
speed  bins.  This  information  is  used  by  the  vibration  diagnostic  rulebase  to  determine  if 
the  source  of  the  vibration  is  on  the  compressor  or  turbine  sections.  Just  below  the 
tracked-order  information,  the  anomaly  detection  features  are  listed  with  check  boxes  to 
display  the  particular  anomaly.  Based  on  the  results  from  the  engine  knowledge-base, 
diagnostic  comments  are  made  to  describe  the  fault  in  more  detail.  A  button  for  accessing 
the  vibration  fault  spectrum  in  question  is  also  provided. 

Within  the  Demol  demonstration  file,  the  HP  and  LP  tracked-order  vibration  amplitudes 
were  both  measured  over  the  “normal”  alarm  levels,  and  therefore  the  “HP  and  LP  shaft 
unbalance  or  possible  misalignment”  was  the  proper  diagnosis. 


♦  Vibration  Diagnostics 


Starboard  Tangential 


j  80  85  90  95  100 
L'_ . ;  NH  (*  MAX) . 


80  85  90  95  100  ! 

_ nh  \zm<i _ j 


!  80  85  90  95  100  |  j  80  85  90  95  100 


NHRMAX1 


NH  {%  MAX] 


Vfcration  Anomaly  Information 


t  NH  Peak 


jl  J  Peak  3 


J  NL  Peak 


[j  B  Band 


Diagnostic  Comments 

Warning :  Overall  power  spectrum  is  high 
Check  spectrum  for  high  frequency  noise 


Warning :  1  x  HP  Vibration 
Out-of-balance  or  misalignment  of 
HP  shaft  -  turbine/compressor 


Vfcration  Source 


■  Compressor 


1 1  J  Turbine 


i  LP  Shaft 


I  ✓]  HP  Shaft 


Fault  Spectrum 
Continue 


Vibration  Diagnostics  Screen 


“Life”  Menu  Bar 


The  last  EHM  screen  to  be  examined  is  related  to  the  “Component  Life”  module.  In  this 
module  the  life  usage  associated  with  the  HP  turbine  blades  and  disk  are  continuously 
monitored  during  each  mission  and  summed  for  all  missions.  Note,  the  inputs  to 
component  lifing  module  are  both  directly  measured  parameters  and  “virtually”  sensed 
parameters.  This  combination  was  concluded  to  give  the  most  accurate  lifing  results  based 
on  the  algorithms  used.  The  outputs  are  separated  into  the  disk  and  blade  components. 
Outputs  specifically  showing  the  average  and  maximum  thermal  and  cetrifugal 
stresses/strains  are  given  above,  while  the  accumulated  life  used  during  the  mission  and 
total  for  all  missions  is  given  below.  Both  LCF  related  to  thermal  and  centrifugal  stresses 
as  well  as  creep  life  are  considered  in  the  lifing  algorithms.  When  an  accumulated  life 
value  reaches  1.0,  then  the  total  life  of  the  component  is  calculated  to  be  used  up 
completely. 
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Component  Life  Screen 


This  is  the  end  of  the  documentation  associated  with  the  first  demonstration  program. 
The  documentation  for  the  second  demonstration  will  not  include  taking  the  user  through 
each  of  the  modules  of  the  EHM  program  as  just  done  with  this  demonstration.  Instead,  it 
is  left  up  to  the  user  to  “click”  through  each  of  the  EHM  screens  during  the  second 
demonstration  file. 

Demonstration  #2 

Once  you  have  selected  “Demo  2”  from  the  dialog  box  show  below,  the  EHM  system  will 
automatically  begin  operation  as  if  the  EHM  system  was  processing  real-time  data  from  an 
engine.  The  EHM  “main  screen”  will  become  active  with  the  instrumentation  panel 
changing  with  the  data  that  is  being  received  from  the  Demo  2  demonstration  file.  The 
various  EHM  system  monitoring  and  diagnostic  screens  can  be  accessed  from  the  top 
menu  bar  and  include  the  Engine  Instrument  Display,  Data  Management,  Health, 
Diagnostic,  and  Life  modules. 


Demo  2  Start-Up  Screen 


During  this  demonstration,  the  only  fault  that  is  detected  and  reported  in  the  alarm  queue 
is  from  the  vibration  health  and  diagnostic  modules.  From  the  top  menu  bar,  select  the 
“Vibration  Health  -  Starboard  Tangential”  diagnostic  screen  and  examine  the  vibration 


spectrums  as  the  speed  of  the  engine  is  increased.  Once  the  HP  tracked-order  amplitude 
gets  in  the  range  of  approximately  0.65  in/sec,  a  yellow  warning  is  displayed.  Quickly 
following  this  warning,  an  alarm  is  detected  from  the  amplitude  rising  over  approximately 
1.0  in/sec.  This  alarm  is  then  reported  to  the  main  alarm  queue.  The  basic  fault  is  caused 
by  “higher  than  normal”  tracked-order  amplitudes  with  respect  to  the  LP  and  HP  shaft 
speeds.  This  fault  is  similar  to  the  vibration  fault  detected  in  the  Demo  1  demonstration 
file.  Although  no  other  faults  are  detected  in  this  demonstration,  the  user  is  encouraged  to 
examine  the  remaining  diagnostic  screens. 
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7.0  Conclusions 


The  SBIR  program  described  herein  has  produced  a  real-time  Engine  Health  Monitoring 
system  that  demonstrates  advanced  diagnostic  classifiers  for  mechanical  and  performance 
fault  detection,  dedicated  sensor  validation,  “virtual”  sensors,  long/short  term  trend 
monitoring  and  real-time  component  lifing  algorithms  for  advancing  the  current  state-of- 
the-art  in  real-time  engine  condition  monitoring  and  diagnostics.  In  particular,  the 
incorporation  of  advanced  fault  pattern  recognition  techniques  (utilizing  back-propagation 
neural  networks,  self  organizing  maps,  and  polynomial  networks)  and  decision  analysis  (i.e. 
fuzzy  logic  and  expert  systems)  into  the  diagnostic  process  has  been  shown  to  yield  great 
benefits  in  terms  of  processing  speed,  robustness,  knowledge  acquisition,  and  adaptability. 
The  real-time  EHM  technologies  have  been  successfully  demonstrated  on  three  engines  at 
the  Rolls-Royce  MAEL  Test  Cells  in  Bristol,  England. 

Further  development  and  demonstration  of  the  real-time  EHM  system  capabilities  are 
ongoing  with  a  program  to  “re-train”  the  EHM  system  for  the  GE  FI 01  engine.  This 
program  is  of  particular  interest  to  the  U.S.  Air  Force  and  in  particular  the  Air  Combat 
Command  (ACC)  in  Oklahoma  City  where  a  large  number  of  the  GE  FlOl’s  are 
maintained.  Successful  demonstration  of  the  EHM  system  during  this  program  could  help 
build  the  necessary  support  required  for  implementing  these  cost  saving  life  monitoring  and 
diagnostic  technologies  for  aging  propulsion  systems.  In  addition,  a  similar  program  is 
being  planned  with  GE  Aircraft  Engines  to  consider  transferring  some  of  the  technologies 
demonstrated  under  the  FI 01  program  to  the  JSF  program. 

A  list  of  the  program’s  significant  technical  benefits  for  applying  AI  and  advanced  life 
prediction  schemes  to  real-time  condition  monitoring,  diagnosis,  and  life  usage  are  as 
follows: 

•  Integration  of  neural  networks  (unsupervised  and  supervised),  fuzzy-logic,  and 
expert  systems  to  identify  engine  anomalies,  both  performance  and  mechanical 
(vibration)  related,  and  in  mm  provide  specific  diagnostics  related  to  the  identified 
fault  in  real-time. 

•  Capability  to  provide  real-time  estimates  of  the  life  being  consumed  from  critical 
engine  components  including  HP  turbine  blades  and  disks.  Virtually  sensed  turbine 
inlet  temperatures,  mass  flow,  etc.  (currently  not  measured)  are  utilized  to  improve 
accuracy  of  the  actual  life  being  accumulated. 

J 

•  Advanced  vibration  diagnostics  that  is  based  on  feature  extraction  from  both 
spectral  “waterfall”  plots  and  tracked-order  amplitudes.  The  results  are  passed 


through  a  fuzzy-logic  decision  analysis  procedure  for  classifying  mechanical  engine 
faults. 

•  Engine  “signature”  based  performance  degradation  monitoring  that  accounts  for 
steady-state  and  pseudo  steady-state  engine  operation.  Self  organizing  maps  cluster 
performance  faults  with  high  degree  of  robustness  with  respect  to  pattern 
uncertainties. 

•  Real-time  sensor  validation  networks  trained  from  “fleet-wide”  engine  test  data 
taken  during  a  wide  range  of  engine  operating  conditions.  Polynomial  networks  are 
implemented  to  recognize  the  non-linear  relationships  among  the  measured 
parameters. 

•  Provides  an  automated  procedure  for  incorporating  data  from  several  knowledge 
sources  including;  analytical  FEM  models,  aerothermal  performance  models, 
empirical/trended  test  data,  and  heuristic  (rules  based)  experience. 


As  previously  mentioned,  the  EHM  system  has  undergone  successful  ground  tests  on 
three  (3)  different  Rolls-Royce  Adour  engines  (Navy  F405)  in  Bristol,  England.  The 
EHM  system’s  capabilities  were  tested  thoroughly  during  each  of  the  three  engine  tests 
with  actual  faults  being  diagnosed  from  test  cell  sensor  faults  and  vibration  signal 
calibration  problems.  In  particular,  a  total  of  three  different  actual  engine  sensor 
anomalies  were  detected  and  diagnosed  as  well  as  some  additional  “seeded”  faults  that 
were  also  diagnosed.  First,  the  T2  (LP  compressor  delivery  temperature)  and  WF  (fuel 
flow)  test  cell  transducers  both  malfunctioned  during  an  initial  engine  test,  both  of 
which  were  detected  and  correctly  diagnosed  in  real-time.  In  addition,  an  HP  and  LP 
shaft  vibration  anomaly  was  also  diagnosed  during  the  first  two  engine  tests.  Overall, 
Rolls  Royce  engineers  were  extremely  pleased  with  the  operation  of  the  EHM  system 
and  summarized  the  testing  results  with  the  following  quote: 

“This  is  a  new  and  probably  first  application  of  artificial  intelligence  techniques  in  a 
real-time,  on-board  engine  monitoring  system  having  the  ability  for  diagnosing 
vibration,  performance,  and  component  life  anomalies  concurrently.  Rolls  Royce 
commends  STI  for  the  successful  demonstration  of  this  novel  system.  ” 

H.  R.  Carr  and  R.  G.  Fox,  Rolls 

Royce,  pic. 
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Section  4.3  Figures 


PERFORMANCE  ANOMALY  DETECTION 


Fuzzy  Logic  Module 


performance 


rulebase 


Fuzzy  Logic  Module _ performance  (Rulebase:  rulebase) 

R1  : 

IF  nl_delta  IS  low  AND  p3_delta  IS  low  AND  t2_delta  IS  low 
AND  t6_de!ta  IS  low  AND  wf_delta  IS  low 
THEN  anomaly  is  ok 
R2  : 

IF  nljdelta  IS  high  AND  (p3_delta  IS  high  OR  p3_delta  IS  med 
OR  p3_delta  IS  low)  AND  (t2_delta  IS  high  OR  t2_delta  IS  med 
OR  t2_delta  IS  low)  AND  (t6_delta  IS  high  OR  t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wf_delta  IS  high  OR  wf_delta  IS  med 
OR  wf_delta  IS  low) 

THEN  anomaly  is  alarm 
R3  : 

IF  p3_delta  IS  high  AND  (nl_delta  IS  high  OR  nl_delta  IS  med 
OR  nl_delta  IS  low)  AND  (t2_delta  IS  high  OR  t2_de!ta  IS  med 
OR  t2_delta  IS  low)  AND  (t6_delta  IS  high  OR  t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wf_delta  IS  high  OR  wf_delta  IS  med 
OR  wfjtelta  IS  low) 

THEN  anomaly  is  alarm 
R4  : 

IF  t2_delta  IS  high  AND  (p3_delta  IS  high  OR  p3_delta  IS  med 
OR  p3_delta  IS  low)  AND  (nl_delta  IS  high  OR  nl_delta  IS  med 
OR  nl_delta  IS  low)  AND  (t6_delta  IS  high  OR  t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wf_delta  IS  high  OR  wf_delta  IS  med 
OR  wf_delta  IS  low) 

THEN  anomaly  is  alarm 
R5  : 

IF  t6_delta  IS  high  AND  (p3_delta  IS  high  OR  p3_delta  IS  med 
OR  p3_delta  IS  low)  AND  (t2_delta  IS  high  OR  t2_delta  IS  med 
OR  t2_delta  IS  low)  AND  (nl_delta  IS  high  OR  nl_delta  IS  med 
OR  nl_delta  IS  low)  AND  (wf_delta  IS  high  OR  wf_delta  IS  med 
OR  wf_delta  IS  low) 

THEN  anomaly  is  alarm 
R6  : 

IF  wf_delta  IS  high  AND  (p3_delta  IS  high  OR  p3_delta  IS  med 
OR  p3_delta  IS  low)  AND  (t2_delta  IS  high  OR  t2_delta  IS  med 
OR  t2_delta  IS  low)  AND  (t6_delta  IS  high  OR  t6_delta  IS  med 
OR  t6_de!ta  IS  low)  AND  (nl_delta  IS  high  OR  nl_delta  IS  med 
OR  nl_delta  IS  low) 

THEN  anomaly  is  alarm 
R7  : 

IF  nl_delta  IS  med  AND  (p3_delta  IS  med  OR  p3_de!ta  IS  low) 

AND  (t2_delta  IS  med  OR  t2_delta  IS  low)  AND  (t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wf_delta  IS  med  OR  wf_delta  IS  low) 

THEN  anomaly  is  warn 
R8  : 

IF  p3_delta  IS  med  AND  (nl_delta  IS  med  OR  nl_delta  IS  low) 

AND  (t2_delta  IS  med  OR  t2_delta  IS  low)  AND  (t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wf_delta  IS  med  OR  wfjtelta  IS  low) 

THEN  anomaly  is  warn 
R9  : 

IF  t2_delta  IS  med  AND  (p3_delta  IS  med  OR  p3_delta  IS  low) 

AND  (n!_delta  IS  med  OR  nl_delta  IS  low)  AND  (t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (wfjtelta  IS  med  OR  wf_delta  IS  low) 

THEN  anomaly  is  warn 
RIO: 

IF  t6_delta  IS  med  AND  (p3_delta  IS  med  OR  p3_delta  IS  low) 

AND  (t2_delta  IS  med  OR  t2_delta  IS  low)  AND  (nl_delta  IS  med 
OR  nl_delta  IS  low)  AND  (wfjdelta  IS  med  OR  wf_delta  IS  low) 

THEN  anomaly  is  warn 
R11  : 

IF  wfjtelta  IS  med  AND  (p3_delta  IS  med  OR  p3_delta  IS  low) 

AND  (t2_delta  IS  med  OR  t2_delta  IS  low)  AND  (t6_delta  IS  med 
OR  t6_delta  IS  low)  AND  (nl_delta  IS  med  OR  nl_delta  IS  low) 
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Section  4.4  Figures 


VIBRATION  ANOMALY  DETECTION 


Anomaly 


Anomaly  (Rulebase:  Anomaly  Detector) 


Fuzzy  Logic  Module _ 

R1  : 

IF  b_band  IS  low  AND  peak_3  IS  low  AND  nljDeak  IS  low 
AND  nhjDeak  IS  low 
THEN  anomaly  is  ok 
R2  : 

IF  nhj>eak  IS  high  AND  (nl_peak  IS  high  OR  nl_peak  IS  med 
OR  nljDeak  IS  low)  AND  (peakJ3  IS  high  OR  peak_3  IS  med 
OR  peak_3  IS  low)  AND  (b_band  IS  high  OR  b_band  IS  med 
OR  b_band  IS  low) 

THEN  anomaly  is  alarm 
R3  : 

IF  nljDeak  IS  high  AND  (nhjDeak  IS  high  OR  nhjDeak  IS  med 
OR  nhjDeak  IS  low)  AND  (peak_3  IS  high  OR  peak_3  IS  med 
OR  peakJ3  IS  low)  AND  (b_band  IS  high  OR  b_band  IS  med 
OR  b_band  IS  low) 

THEN  anomaly  is  alarm 
R4  : 

IF  peak_3  IS  high  AND  (nl_peak  IS  high  OR  nljDeak  IS  med 
OR  nljDeak  IS  low)  AND  (nh_peak  IS  high  OR  nh_peak  IS  med 
OR  nhjDeak  IS  low)  AND  (b_band  IS  high  OR  b_band  IS  med 
OR  b_band  IS  low) 

THEN  anomaly  is  alarm 
R5  : 

IF  b_band  IS  high  AND  (nljDeak  IS  high  OR  nljDeak  IS  med 
OR  nljDeak  IS  low)  AND  (peak__3  IS  high  OR  peak_3  IS  med 
OR  peak_3  IS  low)  AND  (nhjDeak  IS  high  OR  nh_peak  IS  med 
OR  nhjDeak  IS  low) 

THEN  anomaly  is  alarm 
R6  : 

IF  b_band  IS  med  AND  (nl_peak  IS  med  OR  nijpeak  IS  low) 

AND  (peak_3  IS  med  OR  peak_3  IS  low)  AND  (nh_peak  IS  med 
OR  nh_peak  IS  low) 

THEN  anomaly  is  warn 
R7  : 

IF  peak_3  IS  med  AND  (nl_peak  IS  med  OR  nl_peak  IS  low) 

AND  (b_band  IS  med  OR  b_band  IS  low)  AND  (nh_peak  IS  med 
OR  nh_peak  IS  low) 

THEN  anomaly  is  warn 
R8  : 

IF  nljDeak  IS  med  AND  (peak_3  IS  med  OR  peak_3  IS  low) 

AND  (b_band  IS  med  OR  b_band  IS  low)  AND  (nhjjeak  IS  med 
OR  nhjDeak  IS  low) 

THEN  anomaly  is  warn 
R9  : 

IF  nhj)eak  IS  med  AND  (peak_3  IS  med  OR  peak_3  IS  low) 

AND  (b_band  IS  med  OR  b_band  IS  low)  AND  (nljjeak  IS  med 
OR  nljDeak  IS  low) 

THEN  anomaly  is  warn 
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APPENDIX  A 


A.l  Neural  Network  Basics 


Neural  networks  are  systems  of  elemental  processing  units  connected  in  a  way  analogous  to  how 
neurons  are  connected  in  the  brain.  Like  the  brain,  neural  networks  exhibit  learning  and 
associative  memory  skills.  A  neural  network  is  trained  to  perform  a  task  by  showing  it  examples 
of  an  input  it  will  receive,  paired  with  the  output  it  is  to  deliver.  The  network  learns  the 
associations  between  these  pairs  of  input  examples  and  corresponding  outcomes,  and  is  able  not 
only  to  reproduce  these  associations,  but  also  to  generalize  these  relationships  for  inputs  that  it 
has  not  encountered  before.  Neural  nets  are  therefore  capable  of  intelligent  interpolation  and 
therefore  make  them  particularly  well  suited  for  this  type  of  application. 

The  artificial  neural  network  can  be  viewed  as  a  collection  of  elemental  processing  units 
massively  interconnected  among  themselves.  Some  of  the  processing  units,  sometimes  called 
nodes,  communicate  with  the  outside  environment.  We  distinguish  between  the  different  types  of 
processing  unit  with  the  following  nomenclature: 

1. )  Input  Nodes:  Receive  signal  from  the  environment 

2. )  Output  Nodes:  Send  signals  to  the  environment 

3 . )  Hidden  Nodes:  No  direct  contact  with  the  environment 


The  processing  unit  or  node  is  the  component  within  neural  networks  where  the  computations  are 
carried  out.  The  input  signal  come  from  either  the  environment  or  other  processing  units,  and 
form  an  input  vector  containing  all  the  inputs.  Figure  A1  is  an  illustration  of  one  processing  unit 


or  node. 


NEURON 

OUTPUT 
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Figure  A1  Neural  Network  Processing  Unit  or  Node 
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Figure  A1  also  shows  weights  corresponding  to  each  input.  These  weights  are  used  to  compute 
the  output  value  of  the  processing  unit.  This  computation  is  performed  by  taking  the  product  of 
each  input  value  xx  and  its  corresponding  weight  w,.  These  products  are  then  summed  together 
and  "passed"  through  a  sigmoidal  activation  function  to  determine  its  final  output  activation 
level.  Other  types  of  activation  function  can  be  used,  but  the  sigmoid  is  the  most  commonly 
used  function. 

When  we  talk  about  neural  network's  abilities  to  learn  cause  and  effect  relationships,  we  are 
really  discussing  the  supervised  learning  procedure.  Supervised  learning  involves  the  task  of 
teaching  the  network  associated  input/output  pairs.  The  network  is  presented  with  data  that 
shows  what  response  (output)  should  be  generated  by  a  given  stimulus  (input).  The  network  then 
self  adjusts  its  internal  parameters  in  order  to  represent  this  underlying  relationship  between  the 
inputs  and  outputs.  This  is  the  basis  for  a  neural  network's  ability  to  generate  appropriate 
outputs  for  all  other  inputs  of  a  similar  category,  even  if  these  inputs  have  never  been  previously 
encountered. 

Neural  Networks  can  also  discover  similarities  between  input  patterns.  In  the  training  technique 
referred  to  as  unsupervised  learning,  the  network  is  shown  various  input  patterns  without  any 
labels  attached  to  them.  The  network  looks  at  the  patterns  presented  to  it,  and  clusters  them  into 
groups  of  similar  patterns  based  on  a  Euclidean  distance  computation.  The  number  of  clusters 
obtained  can  be  changed  by  increasing  or  decreasing  the  cluster  center  radius.  This  changes  the 
criterion  of  what  constitutes  similarity,  and  therefore  changes  the  number  of  patterns  within  each 
cluster. 


A.2  Fuzzy  Logic  Basics 

Fuzzy  logic  is  a  programming  tool  that  is  capable  of  incorporating  imprecise  or  ambiguous 
information  into  algorithmic  expressions.  Flowever,  contrary  to  its  name  “fuzzy”,  the 
mathematics  involved  are  based  on  precise  and  rigorous  calculations  with  respect  to  fuzzy  sets  or 
membership  functions.  The  four  basic  processes  required  to  develop  fuzzy  logic  systems  are 
fuzzification,  rulebase  development,  inference,  and  defuzzification.  The  fuzzification  process 
begins  with  the  development  of  membership  functions  which  relate  linguistic  variables  like 
“cool”,  “hot”,  and  “cold”  to  particular  numerical  ranges  used  in  the  “fuzzy”  calculations.  For 
instance,  “cool”  might  have  a  membership  value  of  1.0  (the  highest  degree  of  membership)  for 
60  degrees  F,  a  membership  of  0.6  for  50  degrees  F,  a  membership  of  0.25  for  40  degrees  F, 
and  a  membership  of  0.0  (no  degree  of  membership)  for  30  degrees  F. 

The  rulebase  development  is  typical  of  any  if/then  rule  set  implemented  in  standard  expert 
systems,  except  the  rules  now  incorporate  the  “fuzzy”  linguistic  variables  that  have  membership 
functions  associated  with  them.  An  example  of  a  rule  would  be;  If  temperature  is  cool,  Then 
velocity  is  medium.  In  this  rule,  temperature  is  the  input  variable  and  velocity  is  the  output 
variable,  both  or  which  have  membership  functions  associated  with  them  that  include  cool,  and 
medium  respectively. 
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The  strategies  for  “inferring”  conclusions/decisions  from  cause-and-effect  relationships  provided 
by  the  rulebase  and  membership  functions  (knowledge  base)  are  often  called  fuzzy  inference 
techniques.  Some  inference  techniques  include;  Product-Sum,  Max-Min,  and  Min-Sum.  The 
first  expression  of  the  inference  technique  name  refers  to  the  method  for  scaling  the  membership 
function  variables.  The  second  expression  refers  to  the  technique  for  combining  the  scaled 
membership  function  variables.  A  more  complete  description  of  the  inference  techniques  is 
given  in  Reference  [12].  The  final  process  of  calculating  a  single  value  from  the  scaling  and 
combining  of  the  variables  described  in  the  membership  functions  is  called  defuzzification. 
Techniques  such  as  Centroid,  Max-height,  and  Max-moment  are  used  to  determine  the  value  that 
best  represents  the  outcome  of  the  fuzzy  rule  evaluations. 
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